[phobos] Time to get ready for the next release

[Robert Jacques]

On Fri, 22 Apr 2011 08:30:41 -0400, Steve Schveighoffer  
<schveiguy at yahoo.com> wrote:
>> From: Robert Jacques <sandford at jhu.edu>
>> To: Discuss the phobos library for D <phobos at puremagic.com>
>> Sent: Thursday, April 21, 2011 11:00 PM
>> Subject: Re: [phobos] Time to get ready for the next release
>>
>>
>> The API design we are talking about is called 'Fluent interface'  
>> (http://en.wikipedia.org/wiki/Fluent_interface). So, as I'd say to a  
>> friend, It's A Thing(TM). And better minds than you and I have used it,  
>> recommend it (when applicable, of course) and implemented it in large,  
>> production quality libraries, etc. It's also completely and totally  
>> true that it violates the concept of a 'property', as defined by C# et  
>> al.. But that doesn't make it a bad design, just a design which wishes  
>> to blur the line between 'field' and 'method'. Notice, how I didn't say  
>> 'property' in there. My point is that there are valid design patterns  
>> which don't fit nicely into the labels of 'field', 'method' and  
>> 'property'.
>
> Notice that in the wikipedia article, in languages where properties  
> exist, the fluent interface defines the property setters separately from  
> the function setters.  e.g. in C#, you have:
>
> public string Color
> {
>    set {color = value;}
>
> }
>
> ...
>
> public IConfigurationFluent SetColor(string color)
> {
>    this.color = color;
>    return this;
>
> }
>
> Note especially the different names SetColor and Color.
>
> Essentially, to re-use the property as a fluent interface is a mutant  
> form of Fluent Interface, and frankly, looks horrendous to me.  If you  
> want both, define both.  a.prop1(5).prop2(7) reads poorly, and is  
> confusing as hell, especially if you replace prop1 with an ambiguous  
> term that could be a noun or a verb.  a.setProp1(5).setProp2(7) looks  
> way better.
>
> Like it or not, the parentheses of a function call are part of the  
> interface.  And the interface is defined by the author, not the caller.   
> It means every time I see a property syntax, I have to go look up what  
> that actually means.  It means as an author, I cannot come up with  
> meaningful short names for my methods, because they might be used in a  
> bastardized way by some clever programmer, and confuse everyone.  It  
> means hello to methods like doRead().  bleh, no thanks.
>
> -Steve

Since you made most of these points in another thread, simply address the  
one additional point made here;
That C# example doesn't use properties at all. And nether does the first  
Java example. Or any of the other initial examples. But they are there to  
present and teach a concept in the simplest way possible, not be  
representative of production code. By the way, if you read down further,  
you'd see that the second Java example, is actually from production code  
and does use the 'mutant' syntactic form: pk.pack( nm  
).gridx(1).gridy(0).fillx();  (and it mixes both verb and prop to boot).