On Thu, 21 Apr 2011 20:14:22 -0400, Jonathan M Davis <[email protected]>
wrote:
On Thu, 21 Apr 2011 18:28:10 -0400, Jonathan M Davis
<[email protected]>
wrote:
>> On Thu, 21 Apr 2011 17:17:33 -0400, Jonathan M Davis
>> <[email protected]>
>>
>> wrote:
[snip]
> I definitely think that chained assignment should be done by calling
the
> setter and then calling the getter, _not_ by using the return value of
> the
> setter. It was my understanding that a setter _couldn't_ return a
value,
> and I
> think that it's just asking for trouble to allow it.
>
> So, I don't think that the chaining that you're attempting to do makes
> any
> sense in the first place when using property functions, unless I've
just
> totally misunderstood what you're doing.
I think you've got the gist of it. :) However I think you missed the
point: The field syntax/chaining combo is a perfectly valid piece of API
design, but can't be expressed under the limits of strict @property
enforcement.
I'd argue that it's _not_ a good piece of API design. It's treating a
function
as a property in some cases and not in others. It makes it impossible to
replace a property function with an actual member variable at a later
date. Is
it a property or isn't it? It really doesn't make sense IMHO to make it
so
that something is sometimes a member variable and sometimes and member
function and that's essentially what you're trying to do.
I do think that there are cases where it makes sense for a function to
be a
property function for a particular overload and not in another (e.g.
std.file.isDir), but that's not currently allowed by the compiler. That's
completely different though from having the same function called as a
property
in some cases and called as a function in others. I do _not_ think that
should
ever be happening.
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'.
So, take off the blinders, step out of the box and try typing 'auto c =
new myClass;' for once. :) And if that scares you, the box will always be
there, but it would nice to acknowledge that the outside of the box
existed. That's all we ask.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
