View mode: basic / threaded / horizontal-split · Log in · Help
February 16, 2013
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
February 17, 2013
Re: DIP26 reworked
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.
February 17, 2013
Re: DIP26 reworked
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!
February 17, 2013
Re: DIP26 reworked
On Sunday, 17 February 2013 at 08:35:44 UTC, Robert wrote:
> 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!

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 ?
February 17, 2013
Re: DIP26 reworked
> 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.
February 17, 2013
Re: DIP26 reworked
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.
Top | Discussion index | About this forum | D home