[phobos] Time to get ready for the next release

[Robert Jacques]

On Thu, 21 Apr 2011 20:14:22 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:
>> On Thu, 21 Apr 2011 18:28:10 -0400, Jonathan M Davis  
>> <jmdavisProg at gmx.com>
>>
>> wrote:
>> >> On Thu, 21 Apr 2011 17:17:33 -0400, Jonathan M Davis
>> >> <jmdavisProg at gmx.com>
>> >>
>> >> 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.