[phobos] Time to get ready for the next release

[David Simcha]

But such a proposal adds more complexity than is justified.

On Wed, Apr 27, 2011 at 12:00 PM, Steve Schveighoffer
<schveiguy at yahoo.com>wrote:

> 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 <dsimcha at gmail.com>
> >To: Discuss the phobos library for D <phobos at puremagic.com>
> >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 <schveiguy at yahoo.com>
> 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- at property functions.
> Likely, they would not care whether @property stays or goes, just as long as
> it doesn't affect how they call non- at 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- at 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
> >phobos at puremagic.com
> >http://lists.puremagic.com/mailman/listinfo/phobos
> >
> >
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110427/497820a6/attachment-0001.html>