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

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

Le 2011-04-21 ? 15:41, David Simcha a ?crit :

> How about the amount of existing code it breaks?

Enforcing @property breaks a lot of code, that's a fact. Just look at what I needed to do to druntime and Phobos to make them compile:

<https://github.com/michelf/druntime/compare/master... at property> <https://github.com/michelf/phobos/compare/master... at property>

(Note: work on Phobos is incomplete.)

What it breaks is generally simple to fix: a missing @property here, wrong call syntax used there...

One other thing is sure, the more time it takes before DMD enforces it the more code will break the day it starts enforcing it. That's simply because more code will have been written.


> How about the fact that it breaks using the same function for both method chaining and with property syntax?

Just use "with":

	with (new Album) {
		name = "hello";
		author = "me";
		group = "them";
		save("/musicinfo/hello.album");
	}

Much cleaner than forcing setters to return the underlying object.

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

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

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

Virtually every discussion I recall about @property has indicated that we expected to have strict semantics eventually. It's been long enough, that I don't remember all of the discussions about @property when it was intially introduced, but I believe any discussion of @property that's happened at all recently and discussed enforcement expected there to be strict semantics eventually. And there have been several confused newbies posting about how @property wasn't enforced.

- Jonathan M Davis

On Thu, Apr 21, 2011 at 4:12 PM, Michel Fortin <michel.fortin at michelf.com>wrote:

> > How about the fact that it breaks using the same function for both method
> chaining and with property syntax?
>
>
> Just use "with":
>
>        with (new Album) {
>                name = "hello";
>                author = "me";
>                group = "them";
>                save("/musicinfo/hello.album");
>        }
>
> Much cleaner than forcing setters to return the underlying object.
>
> NOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!

This is about the 16 billionth time someone has suggested "with" as a solution, and every time I am forced to point out yet again that with() doesn't cut it.

auto hist = Histogram(someArray, 100)
    .barColor(getColor(255, 0, 0))   // Returns a Histogram
    .toFigure  // Returns a Figure
    .title("A histogram");

Try doing that anywhere near as succinctly with a with statement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110421/bf030e5d/attachment.html>

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.

FYI, Wikipedia's article on uniform access is great.

http://en.wikipedia.org/wiki/Uniform_access_principle

On Thu, Apr 21, 2011 at 4:30 PM, Robert Jacques <sandford at jhu.edu> 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.
>
>
> _______________________________________________
> 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/874acac7/attachment-0001.html>

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?

>> > 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.
>
> Virtually every discussion I recall about @property has indicated that we
> expected to have strict semantics eventually. It's been long enough,
> that I
> don't remember all of the discussions about @property when it was
> intially
> introduced, but I believe any discussion of @property that's happened at
> all
> recently and discussed enforcement expected there to be strict semantics
> eventually. And there have been several confused newbies posting about
> how
> @property wasn't enforced.

And virtually every discussion you've every had has been with/inside a pro-properties members on D (which happens with many new feature discussions). When the @property group finally got some traction with Walter/Andrei (with the zero-argument delegate use case), it was asked if method-as-properties was slated for eventual removal (i.e. if @property was to be strict), and Walter responded that method-as-properties wasn't going to be removed.

I'm feeling like there might be some miscommunication here. A function tagged @property would behave identically under both 'loose' and 'strict' semantics. The difference is the 'loose' semantics implies that method-as-properties also exists. 'strict' semantics removes the method-as-properties feature from the language.

Le 2011-04-21 ? 16:16, David Simcha a ?crit :

> This is about the 16 billionth time someone has suggested "with" as a solution, and every time I am forced to point out yet again that with() doesn't cut it.

I already regret suggesting "with" because this is not what this thread is about.

My original question is about whether I should make a pull request for the 5 commits that bring @property enforcement as an experimental feature, or whether I should extract the two commits that fix auto return problems and make a separate pull request for them (which is a little more work for me).

And also, per the thread's title, it's about whether any of that should be part of the next release or not.

Whether the -property switch enforces things correctly or not can be decided and changed later.

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

Right.  This discussion is about what those pull requests should actually do and why.

On Thu, Apr 21, 2011 at 4:42 PM, Michel Fortin <michel.fortin at michelf.com>wrote:

> Le 2011-04-21 ? 16:16, David Simcha a ?crit :
>
> > This is about the 16 billionth time someone has suggested "with" as a solution, and every time I am forced to point out yet again that with() doesn't cut it.
>
> I already regret suggesting "with" because this is not what this thread is about.
>
> My original question is about whether I should make a pull request for the 5 commits that bring @property enforcement as an experimental feature, or whether I should extract the two commits that fix auto return problems and make a separate pull request for them (which is a little more work for me).
>
> And also, per the thread's title, it's about whether any of that should be part of the next release or not.
>
> Whether the -property switch enforces things correctly or not can be decided and changed later.
>
> --
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
>
>
>
> _______________________________________________
> 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/f8bdfbc2/attachment.html>

> 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. 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. Every @property functions is called as a property and no function which isn't @property is called as a property.

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.

- Jonathan M Davis