I don't want to keep arguing this, but I feel compelled to keep re-iterating:
The delegate return problem is nice to solve but is *NOT* the main thing that
@property solves. One can already call the delegate using a double set of
parentheses, and it's not common to have a property that returns a delegate.
The main problem solved is that one cannot simply use property syntax where it
was not intended. This is the piece that is not yet implemented.
I understand it breaks your design. But I've already said my opinion on why
this is worth breaking those designs. We differ in opinion, and I can't really
say one way is 100% right, it's a compromise.
I would point out that if D adopted strict properties before you learned it,
you probably would have simply gravitated towards a different method of
achieving the same design. I don't have any proof that this is the case,
except to look at other languages with strict properties that have achieved
your designs without issue (just with slightly different semantics).
--------
I also thought of this last night, not sure if it is something you could live
with. But one way to allow fluent programming without explicitly having to
enable it is to have a wrapper type that enables the fluent interface.
If we assume propN symbols are @property functions:
// before
mytype.prop1(1).prop2(2);
// after
fluent(mytype).prop1(1).prop2(2);
Essentially, the fluent template would create a wrapper that intercepts calls
to @property functions and does something like:
typeof(this) prop1(int x)
{
wrapped.prop1 = x;
return this;
}
It would actually work on plain fields as well ;)
I've tried to write a wrapper type that did something like this, but I ran into
some bugs with opDispatch. I ended up making a wrapper type that wasn't as
universal (see dcollections' trackLength function).
However, with those bugs fixed, one then has the power to create a design that
enforces proper property usage, and also is able to use the fluent method
without having to define extra functions where one wants to use the fluent
method. This method at least informs the reader that you are overriding the
default usage (via the fluent wrapper), and it is also DRY.
Does this sound reasonable? I can agree with putting off strict properties
until such a wrapper is implementable (I'd like to use this technique in
dcollections anyways, see the trackLength function for my workaround-ish
implementation of a similar wrapper).
-Steve
>________________________________
>From: David Simcha <[email protected]>
>To: Discuss the phobos library for D <[email protected]>
>Sent: Wednesday, April 27, 2011 11:25 AM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>
>
>
>On Wed, Apr 27, 2011 at 9:54 AM, Steve Schveighoffer <[email protected]>
>wrote:
>
>
>>Given that those arguing against tight semantics likely don't use @property,
>>I think they are not really concerned with the semantics of @property
>>functions, they only care about non-@property functions. Likely, they would
>>not care whether @property stays or goes, just as long as it doesn't affect
>>how they call non-@property fucntions. Correct me if I'm wrong, guys.
>>
>>
>Right. I think @property solves a somewhat important problem by
>disambiguating the case of returning delegates, etc. Whether solving this
>problem is worth the complexity it adds to the language is something I'm
>neutral on. Basically, I really don't care what happens with @property as
>long as designs that rely on non-@property functions behaving as they do
>currently don't break.
>
>I wouldn't care if we were only talking about breaking code in trivial ways,
>but we're talking, as you mention, about breaking existing designs, and
>designs I happen to like. I understand you don't like them, but that's not
>the point. The point is that we're talking about very non-trivial breakage of
>existing code, and @property could solve the main problem it was meant to
>solve without doing so by having loose semantics. This is what really ticks
>me off about @property with strict semantics.
>
>_______________________________________________
>phobos mailing list
>[email protected]
>http://lists.puremagic.com/mailman/listinfo/phobos
>
>
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
