> 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

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.

Second, there are situations where you want to be able to support:

a.prop1 =  5;

and

auto b = a.prop1(5).prop2(6);

or simply

a.prop1(5).prop2(6).prop3(7);


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();

But that's a slightly different issue.

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

Oh. I suppose that that could be legal if the value of the property was callable with a single integer and that function returned a value. If so, that should be legal. But other than that, I can't think of why it would be legal to do that, or make any sense to for that matter.

- Jonathan M Davis

On Thu, 21 Apr 2011 17:54:34 -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?
>
> Oh. I suppose that that could be legal if the value of the property was
> callable with a single integer and that function returned a value. If
> so, that
> should be legal. But other than that, I can't think of why it would be
> legal
> to do that, or make any sense to for that matter.
>
> - Jonathan M Davis

See: http://en.wikipedia.org/wiki/Method_chaining and specifically, http://en.wikipedia.org/wiki/Fluent_interface

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

> 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. 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). That wouldn't be calling it as a property, and the setter shouldn't be returning anything.

Are you trying to set prop1 to 5, then set prop1's prop2 to 6, and then set prop2's prop3 to 7? As long as setters return void (which they're supposed to do), that doesn't make any sense at all. 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. 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 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.

> 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. If the first version doesn't work, it's a bug. http://d.puremagic.com/issues/show_bug.cgi?id=2883 relates to this.

- Jonathan M Davis

Le 2011-04-21 ? 17:54, Robert Jacques a ?crit :

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

Indeed. You'd expect the property to return the value you set to it.


> Second, there are situations where you want to be able to support:
> 
> a.prop1 =  5;
> 
> and
> 
> auto b = a.prop1(5).prop2(6);

But here you have a dilemma. To work like "x = y = 1" above, "a.prop1 = 5" should return "5". But to work with chaining, "a.prop1(5)" should return "a". How do you make that work?


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

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.

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

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

On Thu, 21 Apr 2011 18:57:18 -0400, Michel Fortin <michel.fortin at michelf.com> wrote:

> Le 2011-04-21 ? 17:54, Robert Jacques a ?crit :
>
>> 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.
>
> Indeed. You'd expect the property to return the value you set to it.
>
>
>> Second, there are situations where you want to be able to support:
>>
>> a.prop1 =  5;
>>
>> and
>>
>> auto b = a.prop1(5).prop2(6);
>
> But here you have a dilemma. To work like "x = y = 1" above, "a.prop1 = 5" should return "5". But to work with chaining, "a.prop1(5)" should return "a". How do you make that work?

Assignment chaining and method chaining are not compatible, as far as I know. I was using "x = y = 1" as a counter-argument; i.e. as an illustration that fields/property assignment could/should have a return value. In the later example, something like `c = a.prop1 = 5` would only work if is(typeof(c) == typeof(a)). So, a.prop1 isn't 100% faithful to the field semantics which generally define what a strict 'property' should be. But on the other hand, the API design of 'a' desires that prop1 be accessible via both method and field style invocation, something that's possible today using Methods-as-Fields but not with @property alone.

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

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

> > 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, and the interchangeability of public member variables and @property functions is supposed to be part of the point of properties in the first place.

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.

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

- Jonathan M Davis

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.

On Thu, Apr 21, 2011 at 6:02 PM, Robert Jacques <sandford at jhu.edu> wrote:

> On Thu, 21 Apr 2011 17:54:34 -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?
>>>
>>
>> Oh. I suppose that that could be legal if the value of the property was
>> callable with a single integer and that function returned a value. If so,
>> that
>> should be legal. But other than that, I can't think of why it would be
>> legal
>> to do that, or make any sense to for that matter.
>>
>> - Jonathan M Davis
>>
>
> See: http://en.wikipedia.org/wiki/Method_chaining and specifically, http://en.wikipedia.org/wiki/Fluent_interface
>
> _______________________________________________
> 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/84367c91/attachment-0001.html>