On Fri, 22 Apr 2011 08:30:41 -0400, Steve Schveighoffer
<[email protected]> wrote:
From: Robert Jacques <[email protected]>
To: Discuss the phobos library for D <[email protected]>
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).
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
