digitalmars.D - DIP26 reworked
Hi guys! Based on the feedback I got in discussions on this newsgroup I reworked DIP26. The new version - emphasizes less on encapsulation as people seem to have a problem with phrases I used. (And I really got carried away a bit on this one) - Clarified the section about UFCS as people seem to think that I am crazy and trying to destroy the range interface for arrays. - In general I tried to make things a bit more clear, especially what it is all about. Thanks for the feedback! Best regards, Robert
Feb 16 2013
On Saturday, 16 February 2013 at 19:06:55 UTC, Robert wrote:Hi guys! Based on the feedback I got in discussions on this newsgroup I reworked DIP26. The new version - emphasizes less on encapsulation as people seem to have a problem with phrases I used. (And I really got carried away a bit on this one) - Clarified the section about UFCS as people seem to think that I am crazy and trying to destroy the range interface for arrays. - In general I tried to make things a bit more clear, especially what it is all about. Thanks for the feedback! Best regards,It still introduce limitation for very poor reasons. You assumed people didn't understood you DIP but in fact, people did.
Feb 16 2013
On Sun, 2013-02-17 at 04:18 +0100, deadalnix wrote:It still introduce limitation for very poor reasons. You assumed people didn't understood you DIP but in fact, people did.Could you please explain what about the DIP is a limitation and how it affects you in practice? Maybe people understood it correctly, but I still don't understand what people don't like. So if you could explain how the DIP affects your code and why you don't like that, this would really help me to understand what the problem is. Thanks!
Feb 17 2013
On Sunday, 17 February 2013 at 08:35:44 UTC, Robert wrote:On Sun, 2013-02-17 at 04:18 +0100, deadalnix wrote:I'm sorry this is reversed logic. You introduce limitation (IE no UFCS setter for instance) it is up to you to justify the tradeoff. Secondly, I still think this proposal is bad for getter as they are now both bad function and bad properties. For instance typeof(a) == int and typeof(&a) == function is really bad. Plus it cascade into all kind of possible weird cases. What about ternary operator ? Coma expressions ?It still introduce limitation for very poor reasons. You assumed people didn't understood you DIP but in fact, people did.Could you please explain what about the DIP is a limitation and how it affects you in practice? Maybe people understood it correctly, but I still don't understand what people don't like. So if you could explain how the DIP affects your code and why you don't like that, this would really help me to understand what the problem is. Thanks!
Feb 17 2013
I'm sorry this is reversed logic. You introduce limitation (IE no UFCS setter for instance) it is up to you to justify the tradeoff.I thought I did, if you disagree I think it is not too much to ask why? I surely might have missed really good use cases, that is why I want to discuss it, so if you have one, please tell me.For instance typeof(a) == int and typeof(&a) == function is really bad. Plus it cascade into all kind of possible weird cases. What about ternary operator ? Coma expressions ?I in fact forgot about those issues, I will check them out. Thanks! Although this critique does not really apply to DIP26, but rather DIP23 (they still need to be resolved as DIP26 builds on the concept of optional parentheses of DIP23) but I would like to know what is bad about the things DIP26 introduces and most importantly why. Thanks again for constructive feedback.
Feb 17 2013
On Sunday, 17 February 2013 at 12:55:46 UTC, Robert wrote:Although this critique does not really apply to DIP26, but rather DIP23 (they still need to be resolved as DIP26 builds on the concept of optional parentheses of DIP23) but I would like to know what is bad about the things DIP26 introduces and most importantly why. Thanks again for constructive feedback.Yes, I oppose the same critic to DIP23.
Feb 17 2013