[phobos] Time to get ready for the next release

[Steve Schveighoffer]

BTW, I didn't mean to take this private, but when a message is sent to 
both the list and me, the list doesn't send me an email, so I end up 
replying to the person directly.

Sorry.


From: David Simcha <dsimcha at gmail.com>
To: Steve Schveighoffer <schveiguy at yahoo.com>
Sent: Friday, April 22, 2011 9:49 AM
Subject: Re: [phobos] Time to get ready for the next release


On 4/22/2011 9:40 AM, Steve Schveighoffer wrote: 

>
>----- Original Message -----
>
>From: David Simcha <dsimcha at gmail.com>
>>To: Steve Schveighoffer <schveiguy at yahoo.com>; Discuss the phobos library for D <phobos at puremagic.com>
>>Cc: 
>>Sent: Friday, April 22, 2011 9:09 AM
>>Subject: Re: [phobos] Time to get ready for the next release
>>
>>On 4/22/2011 8:43 AM, Steve Schveighoffer wrote:
>>
>>There are a couple problems with this.
>>>
>>>First, there is the WTF factor when you want to set multiple colors with 
>>>
>>the same value:
>>
>>hist1.barColor = hist2.barColor = getColor(255, 0, 0);
>>>
>>>WTF? this is an error? But this works (enjoy the clarity of this):
>>>
>>>hist1.barColor = (hist2.barColor = getColor(255.0, 0)).barColor;
>>>
>>Yeah, it would be nice if the first one worked, but in a plotting library the 
>>second is more useful in practice.  When it comes to minor details like this, 
>>IMHO convenience is more important than consistency.  Maybe if strict semantics 
>>are implemented, this could be solved by allowing property to be overloaded 
>>against non-property and defining a fluent mixin to define both in a single line 
>>of code.  Defining both manually is anti-DRY and not even worth considering.  
>>IMHO they should have the same name because it's less crap to remember.
>>
>I think it would be enough to generate the setX version by giving it X.  I.e.:
>
>@property int x(int newval) { return _x = newval;}
>
>mixin(fluent!"x");  => typeof(this) setX(int newval) { x = newval; return this;}
>
>I don't agree that the name of the fluent setter and the property should be identical.  IMO, it's only this way because it's a cute trick, one which has ambiguity issues in the general case.  In other words, if you didn't have functions-as-properties in the D language, would you feel it is the "right thing"?  I have never seen anyone want this kind of stuff in languages that have strict properties.  They code along happily without complaint :)
>

One difference is that I've already written the code, it works well and I don't want it to break now that D is "stable".  The other is that people in other languages have never been exposed to the D way and don't know any better.  The third is that, other than enforcing your vision of "correct" API design and making D more of a bondage-and-discipline language, I can't see what strict semantics accomplishes over loose semantics that would justify breaking anything that already exists and is even remotely useful.  Loose semantics solve the ambiguity problem that @property was meant to solve.  Strict semantics create problems like breaking certain API designs (whether these are "good" designs is subjective and should be decided by the library designer, not the language designer) and don't solve any additional ones.

---------


In this case, it's not actually the library designer, but the user of the library that is deciding the 
semantics.  Big difference, and my huge problem with D's properties.

With strict properties, the power is to the library designer to 
decide on semantics.  With loose properties, it's to the user.  You can 
think you are creating a usable API, but it's still possible to abuse 
it.

In other words, loose properties prevents *my* designs, even if it 
makes *your* usage possible.  Note that it's your usage, *not* your design 
that you are enforcing.  The API is beyond your control since the user 
is free to call however he/she wants.

So I think the language shouldn't hinder the library author's designs in favor of the caller abusing usage.


-Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/2df57f12/attachment.html>