[phobos] Time to get ready for the next release

[Steve Schveighoffer]

>________________________________
>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