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:
>> >> On Thu, 21 Apr 2011 16:14:22 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
>> >>
>> >> wrote:
>> >> >> On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
>> >> >>
>> >> >> wrote:
>> >> >> >> How about the amount of existing code it breaks? How about the
>> >>
>> >> fact
>> >>
>> >> >> >> that
>> >> >> >> it breaks using the same function for both method chaining and
>> >>
>> >> with
>> >>
>> >> >> >> property syntax?
>> >> >> >
>> >> >> > Something like
>> >> >> >
>> >> >> > auto b = a.prop1.prop2.prop3;
>> >> >> >
>> >> >> > should work. I doesn't at present, but it should. There's a bug
>> >>
>> >> report
>> >>
>> >> >> > on it.
>> >> >>
>> >> >> What about auto b = a.prop1(5).prop2(6).prop3(7); ?
>> >> >
>> >> > I'd consider that to be the same. It should work, but it doesn't.
>> >> > There's a
>> >> > bug report for it.
>> >>
>> >> Ahem, so you'd consider auto b = a.prop1(7); valid code under strict
>> >> property rules?
>> >
>> > Oh wait. You're right. I didn't read that right. No, that wouldn't be
>> > legal.
>> > That would be both getting and setting. Why would you even try and do
>> > that
>> > with a property, let alone with several chained together?
>> >
>> > - Jonathan M Davis
>>
>> First, remember that basic assignments can be chained: x = y = 1; So a property should never return void, whether it's a setter or a getter logically.
>
> Actually, setters _should_ return void. The chaining should be done by
> calling
> both the getter and setter functions. The other options is a property
> function
> which takes nothing but returns a ref. In either case, the chaining would
> work.

But that would be changing the fundamental meaning of the expression from

x = y = 1;

to

x = y, y = 1;

>> Second, there are situations where you want to be able to support:
>>
>> a.prop1 = 5;
>
> Okay. So the setter property prop1 gets called and given a value of 5.
> That's
> perfectly normal.
>
>> and
>>
>> auto b = a.prop1(5).prop2(6);
>>
>> or simply
>>
>> a.prop1(5).prop2(6).prop3(7);
>
> Those don't look like property calls at all unless prop1, prop2, and
> prop3 all
> return a value which is callable with a single integer.

Quite correct. I'm not using field call syntax. I'm using method syntax.

> I don't see the
> problem. I don't see how this relates to
>
> a.prop1 = 5;
>
> If prop1 is setter property function, a.prop1 = 5; makes sense, but then
> it
> doesn't make sense to call it as a.prop1(5).

prop1 is like schrodinger's cat; sometimes you want to call it like a setter property and sometimes you want to call it like a method.

> That wouldn't be calling it as a
> property, and the setter shouldn't be returning anything.

For this example's case, let's let prop1 return this.

> Are you trying to set prop1 to 5, then set prop1's prop2 to 6, and then
> set
> prop2's prop3 to 7?

Yes.

> As long as setters return void (which they're supposed to
> do), that doesn't make any sense at all.

The setter's aren't returning void.

> A property function is either a
> getter by taking nothing and returning a value, a setter by returning
> nothing
> and taking a value, or both by taking nothing and returning a ref.

Actually, since assignments have a result, a setters can also return a value and still be logically correct. You've also forgotten the setter via getter ref return, which is often used for forwarding/aliasing.

> I don't see
> how you could have a getter which took a value or a setter which
> returned one.
>
> @property T prop1(T val){...}
>
> You couldn't call that as a getter, since something like
>
> auto b = a.prop1;
>
> wouldn't have a value to pass as the parameter. I suppose that
>
> a.prop1 = 7;
>
> would work with that definition for prop1, but you'd be throwing away the return value unless you did something like
>
> auto b = a.prop1 = 7;
>
> and then something like
>
> auto c = a.prop1;
>
> would be inconsistent with
>
> auto b = a.prop1 = 7;
>
> because in you're using the exact same syntax to mean two very different
> things: in one case a.prop1 is returning using the getter and in
> another, it's
> returning using the setter. Given the fact that assignment is done right
> to
> left, the compiler can probably figure out to use the setter's return
> value
> rather than calling the getter, but if it doesn't assume that, then it's
> ambiguous.

I responded to this in another thread.

> 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.

>> syntactically. There's also times/uses for functions to be chained together using property syntax i.e.
>>
>> a.verb1.verb2.verb3.verb4;
>>
>> instead of
>>
>> a.verb1().verb2().verb3().verb4();
>
> If they're properties, the first version is correct. If they're not properties, then the second version is correct.

Good question. Should they be properties? Or methods? Which syntax do you think is cleaner? Better? Other metric I haven't thought of?

> 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:
> >> >> On Thu, 21 Apr 2011 16:14:22 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> >> >> 
> >> >> wrote:
> >> >> >> On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> >> >> >> 
> >> >> >> wrote:
> >> >> >> >> How about the amount of existing code it breaks? How about the
> >> >> 
> >> >> fact
> >> >> 
> >> >> >> >> that
> >> >> >> >> it breaks using the same function for both method chaining and
> >> >> 
> >> >> with
> >> >> 
> >> >> >> >> property syntax?
> >> >> >> > 
> >> >> >> > Something like
> >> >> >> > 
> >> >> >> > auto b = a.prop1.prop2.prop3;
> >> >> >> > 
> >> >> >> > should work. I doesn't at present, but it should. There's a bug
> >> >> 
> >> >> report
> >> >> 
> >> >> >> > on it.
> >> >> >> 
> >> >> >> What about auto b = a.prop1(5).prop2(6).prop3(7); ?
> >> >> > 
> >> >> > I'd consider that to be the same. It should work, but it doesn't.
> >> >> > There's a
> >> >> > bug report for it.
> >> >> 
> >> >> Ahem, so you'd consider auto b = a.prop1(7); valid code under strict
> >> >> property rules?
> >> > 
> >> > Oh wait. You're right. I didn't read that right. No, that wouldn't be
> >> > legal.
> >> > That would be both getting and setting. Why would you even try and do
> >> > that
> >> > with a property, let alone with several chained together?
> >> > 
> >> > - Jonathan M Davis
> >> 
> >> First, remember that basic assignments can be chained: x = y = 1; So a property should never return void, whether it's a setter or a getter logically.
> > 
> > Actually, setters _should_ return void. The chaining should be done by
> > calling
> > both the getter and setter functions. The other options is a property
> > function
> > which takes nothing but returns a ref. In either case, the chaining would
> > work.
> 
> But that would be changing the fundamental meaning of the expression from
> 
> x = y = 1;
> 
> to
> 
> x = y, y = 1;

Why? It should be

y = 1;
x = y;

Assignment is done from right to left, not left to right.

x = y = 1;

should have identical semantics to

y = 1;
x = y;

It's true that in the case of an overloaded opAssign, it might not, but when it's not, it's pretty much guranteed to be a bug unless the programmer is trying to do something weird, which would almost certainly be an abuse of overloaded operators. So,

auto b = a.prop1 = 3;

should translate to

a.prop1 = 3;
auto b = a.prop1;

> >> Second, there are situations where you want to be able to support:
> >> 
> >> a.prop1 = 5;
> > 
> > Okay. So the setter property prop1 gets called and given a value of 5.
> > That's
> > perfectly normal.
> > 
> >> and
> >> 
> >> auto b = a.prop1(5).prop2(6);
> >> 
> >> or simply
> >> 
> >> a.prop1(5).prop2(6).prop3(7);
> > 
> > Those don't look like property calls at all unless prop1, prop2, and
> > prop3 all
> > return a value which is callable with a single integer.
> 
> Quite correct. I'm not using field call syntax. I'm using method syntax.
> 
> > I don't see the
> > problem. I don't see how this relates to
> > 
> > a.prop1 = 5;
> > 
> > If prop1 is setter property function, a.prop1 = 5; makes sense, but then
> > it
> > doesn't make sense to call it as a.prop1(5).
> 
> prop1 is like schrodinger's cat; sometimes you want to call it like a setter property and sometimes you want to call it like a method.
> 
> > That wouldn't be calling it as a
> > property, and the setter shouldn't be returning anything.
> 
> For this example's case, let's let prop1 return this.
> 
> > Are you trying to set prop1 to 5, then set prop1's prop2 to 6, and then
> > set
> > prop2's prop3 to 7?
> 
> Yes.
> 
> > As long as setters return void (which they're supposed to
> > do), that doesn't make any sense at all.
> 
> The setter's aren't returning void.
> 
> > A property function is either a
> > getter by taking nothing and returning a value, a setter by returning
> > nothing
> > and taking a value, or both by taking nothing and returning a ref.
> 
> Actually, since assignments have a result, a setters can also return a value and still be logically correct. You've also forgotten the setter via getter ref return, which is often used for forwarding/aliasing.
> 
> > I don't see
> > how you could have a getter which took a value or a setter which
> > returned one.
> > 
> > @property T prop1(T val){...}
> > 
> > You couldn't call that as a getter, since something like
> > 
> > auto b = a.prop1;
> > 
> > wouldn't have a value to pass as the parameter. I suppose that
> > 
> > a.prop1 = 7;
> > 
> > would work with that definition for prop1, but you'd be throwing away the return value unless you did something like
> > 
> > auto b = a.prop1 = 7;
> > 
> > and then something like
> > 
> > auto c = a.prop1;
> > 
> > would be inconsistent with
> > 
> > auto b = a.prop1 = 7;
> > 
> > because in you're using the exact same syntax to mean two very different
> > things: in one case a.prop1 is returning using the getter and in
> > another, it's
> > returning using the setter. Given the fact that assignment is done right
> > to
> > left, the compiler can probably figure out to use the setter's return
> > value
> > rather than calling the getter, but if it doesn't assume that, then it's
> > ambiguous.
> 
> I responded to this in another thread.
> 
> > 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.

> >> syntactically. There's also times/uses for functions to be chained together using property syntax i.e.
> >> 
> >> a.verb1.verb2.verb3.verb4;
> >> 
> >> instead of
> >> 
> >> a.verb1().verb2().verb3().verb4();
> > 
> > If they're properties, the first version is correct. If they're not properties, then the second version is correct.
> 
> Good question. Should they be properties? Or methods? Which syntax do you think is cleaner? Better? Other metric I haven't thought of?

That depends entirely on what you're doing. If it's really a verb rather than a noun, then the second syntax would be correct, since it's highly unlikely that you're going to find a verb which conceptually makes sense as a property. In the general case, nouns should be properties and verbs should be functions, but that's up to the programmer who's writing the functions. That's not really the question here. The question is what to do about the property _syntax_ and @property, not whether a particular function should be marked with @property.

- Jonathan M Davis

Since you brought up std.parallelism, there's one renegade issue I need to look into pronto if we're going to get it out for next release.  It seems to cause access violations on Windows when compiled as part of the Phobos unit tests.  However, I doubt this is a bug in std.parallelism as opposed to either DMD or my makefile changes because:

1.  std.parallelism passes all its unit tests when compiled by itself.

2.  It only happens on Windows.

3.  If I put a print statement at the beginning of the first unit test of std.parallelism, it never prints before the access violation occurs.

I don't even know if the access violation is happening at compile time or runtime, since the way Phobos unittests work on Windows it's non-trivial to tell.

On Thu, Apr 21, 2011 at 3:12 AM, Don Clugston <dclugston at googlemail.com>wrote:

> It's now been two months since the last release, and there have been
> huge compiler improvements.
> Note also that there were a couple of very bad regressions in 2.052,
> so I think we really need a release ASAP.
> We've now achieved minimal stability again (all green on the auto-tester).
>
> Here's the things which are blockers for the next release:
>
> From the compiler side:
> * struct destruction of temporaries (seems like we have a chance of
> fixing this soon)
> * fixing the regressions from my CTFE/const folding changes (Fixes are
> here: https://github.com/D-Programming-Language/dmd/pull/37).
> * a few things haven't been backported to D1 yet
> druntime:
> * clean up Windows DLL support
> phobos:
> * nothing that I know of
>
> Looks as though will be time to get std.parallelism in. But otherwise,
> if you have anything you'd like to get into the next release, please
> indicate so now.
> _______________________________________________
> 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/20110421/786e41d0/attachment.html>

On Thu, 21 Apr 2011 19:26:16 -0400, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

>> On Thu, 21 Apr 2011 17:17:27 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
>>
>> wrote:
>> >> On Thu, 21 Apr 2011 15:41:17 -0400, David Simcha <dsimcha at gmail.com>
>> >>
>> >> wrote:
>> >> > On Thu, Apr 21, 2011 at 3:39 PM, Jonathan M Davis
>> >>
>> >> [snip]
>> >>
>> >> >> I know that there are a number of people on the list -
>> particularly
>> >> >> newer
>> >> >> posters - who fully expect @property to be strict and are surpised
>> >>
>> >> when
>> >>
>> >> >> it
>> >> >> isn't. And I see _zero_ problem with strong property enforcement
>> as
>> >> >> long as
>> >> >> the compiler isn't buggy with regards to properties (which it
>> >>
>> >> currently
>> >>
>> >> >> is).
>> >> >> So, I'm 100% behind strict enforcement.
>> >> >>
>> >> >> - Jonathan M Davis
>> >>
>> >> What about the fact that no two people can agree what should and
>> >> shouldn't
>> >> be a property? Or, more practically, that third party library A won't
>> >> conform with organization B's coding policies? Or how about that an
>> O(1)
>> >> property which gets re-factored into a big expensive O(N) operation
>> >> (i.e.
>> >> see bug 5813) Or ranges/containers that may all have different mixes
>> of
>> >> function-like methods and field-like methods. Speaking of templates,
>> >> what
>> >> about how well/poorly opDispatch, etc compose with @property? Oh, and
>> >> then
>> >> there are entire articles against the @property solution to the
>> >> field/method syntax problem in computer science literature (look up
>> the
>> >> Uniform access principle used in Ruby and Eiffel).
>> >>
>> >> Also, surprise isn't necessarily a bad thing. Methods-as-properties
>> >> surprised me I received when I first started using D and it put a
>> >> massive
>> >> smile of joy onto my face in the process.
>> >
>> > It's a property if it's marked with @property. If it's not marked with @property, it isn't.
>>
>> The concept of a property is entirely synthetic. It grew out of the
>> desire
>> to utilize field access syntax with methods. It's also somewhat fluid
>> between languages, since in some it's exclusive, and in others it's not.
>>
>> > Programmers can argue until they're blue in the face
>> > about whether a function should be marked with @property and thus used
>> > as a
>> > property or not, but by strictly enforcing @property, it becomes
>> > completely
>> > consistent.
>>
>> But that's exactly the problem: without consensus _enforced_ consistency means adapting yourself to one or more programming styles/school-of-thought simultaneously.
>
> It's enforced only insomuch as a function marked as @property then must
> use
> property syntax, and those not marked with @property can't use property
> syntax. If that's not the case, then what is the point of @property?
> What does
> it do? The _only_ case which I see where it gives you _anything_ is that
> @property could help distinguish where a callable value is returned by a
> getter, but if you're allowing property functions to be called without
> the
> property syntax, then that introduces an ambiguity which renders even
> that
> benefit of @property useless.

First, you've correctly identified the point of @property. And second, I believe everyone wants calling @property functions using parenthesizes to be disabled. Honestly, so far @property is only a keyword in D, which is somewhat confusing to D newbies.

> Allowing for @property functions to be called with parens or
> non- at property
> functions to be called without parens leads to major inconsistencies in
> usage
> of functions, and generally makes @property pointless. Even if you make
> it so
> that @property functions can't be called with parens while allowing non-
> @property functions to be called without them, then that leads to
> inconsistent
> syntax for function calls and makes it harder to know whether something
> is
> actually a property function or not.

Why is this a benefit? Since your concept of a 'property' differs from mine, @property can only muddy the waters (unless we're both writing code using the same standards document). Being able to switch between call styles, allows me to self document my own (or my company's) guide-lines into the code. Besides, why should I care if something is a 'property' function or a regular function? or even a field, for that matter? There's field syntax and there's method syntax, but why should the library care how I choose to access their code? They don't have to read/review it. I (and my team/managers, etc) do.

> I really don't understand what benefit
> there is in not strictly enforcing @property. Yes, the change will break
> code,
> but if you don't make it, then very nearly the only benefit of @property
> is to
> serve as documentation saying that that was the way that the programmer
> who
> wrote the function intended it to be called.

First, strictly enforcing @property, has to provide a tangible benefit in order to justify breaking code. (Well, beyond @property calls using ()s) Second, both David and I have been pointing out use cases and examples of code and API designs which fundamentally can not be expressed under a strict @property enforcement.

>> > Every @property functions is called as a property and no function which isn't @property is called as a property.
>>
>> But the fact that you're arguing this point shows that this isn't true.
>> The issue is that unlike fields, functions, objects, etc, no two people
>> really have the same concept of a 'property' in their heads. So when you
>> say 'property' and I say 'property', we can mean very different things.
>> This ambiguity is something fairly rare in programming languages; we
>> expect that 'noun_X' has a single specific meaning/concept and it
>> doesn't.
>> So when someone talks about a 'property' they really mean as implemented
>> in C# (or Java or Python, etc).
>>
>> Sometimes I wonder if this is all a nomenclature issue; if Methods-as-Properties was simply called Methods-as-Fields and it was explained somewhere prominently as something unique to D with examples/benefits X/Y/Z, would anyone have an issue with it?
>
> Yes. There will always be arguments over whether something is
> conceptually a
> property and should be marked with @property. But as far as the language
> is
> concerned, if @property defines whether the property syntax is used or
> not,
> then the programmer writing the function can dictate whether a function
> is a
> property function or not, and the calling of that function is then
> completely
> consistent. It also allows for the programmer to later make it so that an
> @property function is a variable instead. If @property isn't enforced,
> then
> you can't do that,


Actually, you can do that without @property in languages which implement
the uniform access principal:
http://en.wikipedia.org/wiki/Uniform_access_principle.
And practically, you often can't revert from a 'property' to a method, due
to inheritance, etc.

> and the interchangeability of public member variables and
> @property functions is supposed to be part of the point of properties in
> the
> first place.

And it's also a major point of Methods-as-Fields, and of the Uniform Access Principal.

> There is a difference between the concept of a property and whether a
> function
> is a property function or not. Programmers can (and sometimes do) argue
> until
> they're blue in the face about whether something is conceptually a
> property or
> not. Ideally, anything which is conceptually a property would either be a
> public member variable or a property function, but it's up to the
> programmer
> to determine whether they'll make a function a property function or not.
> Once
> it's a property function, then it should be treated as a property and
> use the
> property syntax. So, the correctness of whether a property function
> actually
> represents a conceptual property is irrelevant as far as calling the
> function
> goes. The programmer who wrote the function made a decision, and then
> that's
> the API. As long as that is strictly enforced by the compiler, it
> eliminates
> ambiguity on the manner. It could be a poor design decision to have made
> it a
> property function, but there's no ambiguity on the part of the compiler
> or in
> how the function should be used.

True, but remember the only ambiguity that exists with the current system is with field of a type which is callable with no arguments being upgraded to a 'property'. And then its mainly an issue of having to fix all the compilation errors, though silent program changes are possible.

>> > And yes, there are definitely bugs with @property. They're going to
>> need
>> > to be
>> > sorted out before @property is enforced, but the fact that bugs exist
>> > doesn't
>> > mean that we should never strictly enforce @property.
>>
>> I've been taking this into account and (hopefully) haven't been holding quality of implementation against @property. If any of my arguments were QoI issues, please let me know.
>
> The lack of chaining on some level at least is a quality of
> implementation
> issue (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=2883 ). Whether
> chaining assignments calls both the getter and the setter or tries to
> use the
> return value of a setter (which it shouldn't have) is primarily a QoI
> issue.
> Most of what you've been discussing hasn't been, but some of it is at
> least
> partially a QoI issue.

Well, I've been assuming that chaining of getters would work. It's method chaining of setters which I've been highlighting and that's not a QoI issue; @property simply can't handle them.

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:
>> >> >> On Thu, 21 Apr 2011 16:14:22 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
>> >> >>
>> >> >> wrote:
>> >> >> >> On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
>> >> >> >>
>> >> >> >> wrote:
>> >> >> >> >> How about the amount of existing code it breaks? How about
>> the
>> >> >>
>> >> >> fact
>> >> >>
>> >> >> >> >> that
>> >> >> >> >> it breaks using the same function for both method chaining
>> and
>> >> >>
>> >> >> with
>> >> >>
>> >> >> >> >> property syntax?
>> >> >> >> >
>> >> >> >> > Something like
>> >> >> >> >
>> >> >> >> > auto b = a.prop1.prop2.prop3;
>> >> >> >> >
>> >> >> >> > should work. I doesn't at present, but it should. There's a
>> bug
>> >> >>
>> >> >> report
>> >> >>
>> >> >> >> > on it.
>> >> >> >>
>> >> >> >> What about auto b = a.prop1(5).prop2(6).prop3(7); ?
>> >> >> >
>> >> >> > I'd consider that to be the same. It should work, but it
>> doesn't.
>> >> >> > There's a
>> >> >> > bug report for it.
>> >> >>
>> >> >> Ahem, so you'd consider auto b = a.prop1(7); valid code under
>> strict
>> >> >> property rules?
>> >> >
>> >> > Oh wait. You're right. I didn't read that right. No, that wouldn't
>> be
>> >> > legal.
>> >> > That would be both getting and setting. Why would you even try and
>> do
>> >> > that
>> >> > with a property, let alone with several chained together?
>> >> >
>> >> > - Jonathan M Davis
>> >>
>> >> First, remember that basic assignments can be chained: x = y = 1; So
>> a
>> >> property should never return void, whether it's a setter or a getter logically.
>> >
>> > Actually, setters _should_ return void. The chaining should be done by
>> > calling
>> > both the getter and setter functions. The other options is a property
>> > function
>> > which takes nothing but returns a ref. In either case, the chaining
>> would
>> > work.
>>
>> But that would be changing the fundamental meaning of the expression from
>>
>> x = y = 1;
>>
>> to
>>
>> x = y, y = 1;
>
> Why? It should be
>
> y = 1;
> x = y;
>
> Assignment is done from right to left, not left to right.
>
> x = y = 1;
>
> should have identical semantics to
>
> y = 1;
> x = y;
>
> It's true that in the case of an overloaded opAssign, it might not, but
> when
> it's not, it's pretty much guranteed to be a bug unless the programmer is
> trying to do something weird, which would almost certainly be an abuse of
> overloaded operators. So,
>
> auto b = a.prop1 = 3;
>
> should translate to
>
> a.prop1 = 3;
> auto b = a.prop1;

Well, so long as it's valid to override opAssign's return value, properties shouldn't use their own semantics. Then again, fixing assignment semantics might be a good idea.

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.

> > Allowing for @property functions to be called with parens or
> > non- at property
> > functions to be called without parens leads to major inconsistencies in
> > usage
> > of functions, and generally makes @property pointless. Even if you make
> > it so
> > that @property functions can't be called with parens while allowing non-
> > @property functions to be called without them, then that leads to
> > inconsistent
> > syntax for function calls and makes it harder to know whether something
> > is
> > actually a property function or not.
> 
> Why is this a benefit? Since your concept of a 'property' differs from mine, @property can only muddy the waters (unless we're both writing code using the same standards document). Being able to switch between call styles, allows me to self document my own (or my company's) guide-lines into the code. Besides, why should I care if something is a 'property' function or a regular function? or even a field, for that matter? There's field syntax and there's method syntax, but why should the library care how I choose to access their code? They don't have to read/review it. I (and my team/managers, etc) do.

One of the points of properties that I've seen commonly discussed in languages in general is the fact that you can more or less seemlessly switch between something being a public member variable and a property function. As soon as you're loose about enforcing property syntax that doesn't work. And the fact that D is loose about it is incredibly bizarre. It's the only language that I know of that works that way. Typically, property syntax is strictly enforced for property functions and completely disallowed for non-property functions. C# definitely works that way.

Property functions are part of the API of a library. The fact that they are property functions is part of that API, just like the names of functions and how many parameters they have is part of the API. So, making it so that @property is strictly enforced such that it strictly defines the syntax for calling a function isn't really any different from requiring that you use a specific name when calling a function. Making it loose instead is actually the sort of thing that is extremely uncommon in programming. Programming syntax is generally very exact.

What it sounds to me like is that you just don't like the idea of property functions and don't want to have to ever use them as property functions. Personally, I think that it is _way_ better than the incredibly lax way that property syntax has been handled in the past. And it seems perfectly normal to me that they'd be just as much a part of the API as the function's name. If @property isn't enforced, then I don't see much point in ever having added it in the first place. The only advantage that I can see with having @property and lax enforcement over no @property at all is the incredibly rare ambiguity with delegates, and I honestly don't think that that problem merits adding @property. Strictly enforcing @property, on the other hand, and making the syntax consistent _is_ well worth it.

- Jonathan M Davis

>________________________________
>From: Robert Jacques <sandford at jhu.edu>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Thursday, April 21, 2011 4:05 PM
>Subject: Re: [phobos] Time to get ready for the next release
>
>On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>
>>> How about the amount of existing code it breaks?? How about the fact that it breaks using the same function for both method chaining and with property syntax?
>> 
>> Something like
>> 
>> auto b = a.prop1.prop2.prop3;
>> 
>> should work. I doesn't at present, but it should. There's a bug report on it.
>
>What about auto b = a.prop1(5).prop2(6).prop3(7); ?

Looks like a poor design.? If a setter property returns anything, it should return the value set.? Otherwise: auto b = a.prop1 = 5; // I would expect b == 5

my solution:

define a setProp1, setProp2, and setProp3 without property semantics.? It also reads better:

auto b = a.setProp1(5).setProp2(6).setProp3(7);


>> As for breaking existing code, _of course_ it's going to. That's to be expected, and I would have thought that that was expected when @property was introduced in the first place.
>
>Actually, no it wasn't expected. @property was introduced with loose semantics, not strict semantics. And, by the way, it was judged worth while with only loose semantics.

I don't know what messages you read, but strict properties were what was approved.? There have been numerous discussions on the NG regarding properties, some pro-strict, some pro-loose, but the one which got the deal done was pro-strict.

The loose semantics were introduced to serve as a translation period, where you could migrate property code to using @property.? From what I remember, Walter tried to turn on strict properties, but found too many errors in Phobos to deal with.? So it has been back-burnered.

Without strict properties, the author of the code cannot enforce usage semantics, and therefore, will lead to ambiguities.? The only exception I can see is calling a function with no arguments which returns void without the parentheses.? It cannot be mistaken for a property getter, because it can't be used as a getter.


-Steve

>________________________________
>From: Robert Jacques <sandford at jhu.edu>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>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

>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Thursday, April 21, 2011 7:36 PM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>The fluent interface is my biggest concern.? Enforcing @property with strict semantics makes it impossible to use a fluent interface and property syntax for the same field.? Again, in Plot2kill, the following pieces of code are equivalent and IMHO should be:
>
>// Code piece 1
>auto hist = Histogram(someArray, 100);
>hist.barColor = getColor(255, 0, 0);
>auto fig = hist.toFigure;
>fig.title = "A histogram";
>fig.xLabel = "XXX";
>
>// Code piece 2:
>auto fig = Histogram(someArray, 100)
>??? .barColor(getColor(255, 0, 0))
>??? .toFigure
>??? .title("A histogram")
>??? .xLabel("XXX");
>
>I consider this a very nice API.? The with statement isn't a good substitute.? I think it's ridiculous to break things like this in the name of ultra-rigid consistency or to solve a few weird corner cases w.r.t. functions that return zero-argument delegates, especially when the zero-argument delegate corner case can be solved by enforcing @property with loose semantics.

There are a couple problems with this.

First, there is the WTF factor when you want to set multiple colors with the same value:

hist1.barColor = hist2.barColor = getColor(255, 0, 0);

WTF? this is an error? But this works (enjoy the clarity of this):

hist1.barColor = (hist2.barColor = getColor(255.0, 0)).barColor;

Second, it looks strange to have a function named barColor.? In an extreme interpretation, I could expect that with barColor, I am barring that color from the object ;)? Not that it would be a common interpretation, but the name looks more ambiguous than say, setBarColor.? There are certainly better cases that could demonstrate my point, as English is full of words that are both nouns or adjectives and also verbs.


My belief is that the function style functions should be differently named from the property style functions, so there is no chance for misinterpretation, and that works fine with strict properties.

-Steve