On Thursday, January 24, 2013 15:45:42 Nick Sabalausky wrote:
> On Thu, 24 Jan 2013 12:51:32 -0500
> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> > No. The complications come from the fact that (a) nobody could agree what should be a @property and what shouldn't;
> 
> No, you merely came up with *some* specific cherry-picked examples that
> sparked *some* debate (with most of the disagreing coming from
> you).
> 
> Stop mischaracterizing what really happened:
> 
> It's well known that you never liked or fully understood the idea of properties in the first place, even by your own admission. So you made a post some number of months back attempting to drum up dissent for properties by stirring up the notion, which just about only you believed, that the choice between property and function is inherently unclear.
> 
> So to "prove" this you cherry-picked some grey area cases (gee,
> occasional grey judgement calls when mapping ideas into code,
> yea, there's something that doesn't happen without @property). You
> succeeded ONLY in proving that there exist *some* cases which may be
> grey-area judgement calls (again, big surprise, occasional grey-area
> judgement calls when writing code). But then you - and ONLY you - took
> this proof that "*some* cases exist" and declared "Look, look, everyone!
> I proved that *nobody* can agree on property vs function *in general*!
> QED!"
> 
> And you continue declaring that non-sequitur to this day.

I've never understood what's so hard about knowing what should and shouldn't be considered a property. It's generally very clear IMHO, and if clarification is needed, C# has some excellent guidelines for it, as a number of people keep pointing out. Really, it comes down primarily to whether a function would make sense as a variable.

> > (b) @property adds
> > noise for everybody for the sake of a corner case (functions
> > returning delegates);
> 
> The only reason functions returning delegates have *ever* been an any issue at all is *purely* because of the insistence on optional parens on arbitrary function calls.

Indeed.

> > (c) the @property discipline failed to align
> > itself in any way with better code quality.
> 
> Ok, now *that* argument is just pure unadulterated bullshit. In languages like C# that have *real* and *completed* property support, yes, the general consensus IS that they DO definitely help. Please take your blinders off, and you'll see that.
> 
> But then there's D, which adds a half-baked and
> incompletely-implemented "properties" - and did so *reluctantly* I
> should add. Leaves it in that broken state untouched for a year or two.
> And now here you are effectively saying "This
> half-designed/half-implemented feature is causing dissent and not
> helping people, therefore the problem must be the whole idea of
> properties and couldn't possibly be due to our broken version of
> them" (for the record - I *do* find D's current properties helpful,
> just not as helpful as they would be if they weren't broken).

I think that you're being too extreme in your language and tone here, but I have to agree.

- Jonathan M Davis

On Thursday, January 24, 2013 13:08:08 Adam Wilson wrote:
> On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
> 
> <SeeWebsiteForEmail@erdani.org> wrote:
> > On 1/24/13 3:45 PM, Nick Sabalausky wrote:
> >> On Thu, 24 Jan 2013 12:51:32 -0500
> >> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
> >> No, you merely came up with *some* specific cherry-picked examples that
> >> sparked *some* debate (with most of the disagreing coming from
> >> you).
> > 
> > I simply mentioned three reasons that came to mind.
> > 
> > Andrei
> 
> While I don't approve of Mr. Sabalausky's tone or attitude,

He does have a tendancy to get out of hand in that regard.

> the crux of
> his argument is logically sound. The problem with @property isn't
> @property, it's D's insistence on optional parens. If paren usage was
> clearly defined then this would be a non-issue. I would like to point out
> that I can't think of another systems/general purpose language that has an
> calling syntax specification as vague and convoluted as D's. C#'s is
> brutally simple. Java's is brutally simple. In C/C++ everything is a
> function or field, so, brutally simple.
> 
> Make D's calling syntax simpler, end optional parens!

Exactly. That's what _should_ have happened. We wouldn't have all of these problems if we'd just gone with a C#-esque property design and never had optional parens. Unfortunately however, optional parens are so popular for at least some use cases (e.g. UFCS), that I don't think that there's much chance of them going away.

- Jonathan M Davis

On 1/24/13 4:06 PM, mist wrote:
> On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu wrote:
>> On 1/24/13 3:58 PM, mist wrote:
>>> Really, all this backwards-compatibility talk is a crap.
>>
>> There's just a lot of evidence that suggests the contrary. Clearly we
>> don't want or like to be conservative, but apparently we need to.
>>
>> Andrei
>
> Do you read and answer only to the first sentence?

It was your second paragraph I quoted.

> Can you honestly say
> "D design is rock solid and correct, we will never be required to make
> any backwards-incompatible change"?

Clearly the design is imperfect.

> If you check those evidences, it was never breaking code alone. It was
> breaking code AND lack of any sane process that allows to stick with
> acceptable release version for longer time. And I suggest to fix the
> right thing, not freeze specs and hope all problems will fade themselves.

My understanding is that we're working on such.


Andrei

On Thursday, 24 January 2013 at 21:09:39 UTC, Adam Wilson wrote:
> The problem with @property isn't @property, it's D's
> insistence on optional parens.

No, this isn't a problem; function call syntax has nothing whatsoever to do with @property because a property is NOT logically a function!

This is so important: a property is supposed to be indistinguishable from a data member. That's the fundamental definition. It should be fully interchangeable for a plain data member.

In other words, as far as the user is concerned, a property *is* a data member, NOT a function!


If functions have optional parens, that changes nothing about how you access data members.... and since properties are data members, it changes absolutely nothing about them either.


If we required data to be accessed with foo->bar and methods to be called [foo:bar].... a property would be accessed foo->bar. The method syntax is irrelevant.

That the property is implemented with a function call should not be known to the user code.

On Thu, 24 Jan 2013 13:19:49 -0800, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Thursday, January 24, 2013 13:08:08 Adam Wilson wrote:
>> On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
>>
>> <SeeWebsiteForEmail@erdani.org> wrote:
>> > On 1/24/13 3:45 PM, Nick Sabalausky wrote:
>> >> On Thu, 24 Jan 2013 12:51:32 -0500
>> >> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>> >> No, you merely came up with *some* specific cherry-picked examples  
>> that
>> >> sparked *some* debate (with most of the disagreing coming from
>> >> you).
>> >
>> > I simply mentioned three reasons that came to mind.
>> >
>> > Andrei
>>
>> While I don't approve of Mr. Sabalausky's tone or attitude,
>
> He does have a tendancy to get out of hand in that regard.
>
>> the crux of
>> his argument is logically sound. The problem with @property isn't
>> @property, it's D's insistence on optional parens. If paren usage was
>> clearly defined then this would be a non-issue. I would like to point out
>> that I can't think of another systems/general purpose language that has an
>> calling syntax specification as vague and convoluted as D's. C#'s is
>> brutally simple. Java's is brutally simple. In C/C++ everything is a
>> function or field, so, brutally simple.
>>
>> Make D's calling syntax simpler, end optional parens!
>
> Exactly. That's what _should_ have happened. We wouldn't have all of these
> problems if we'd just gone with a C#-esque property design and never had
> optional parens. Unfortunately however, optional parens are so popular for at
> least some use cases (e.g. UFCS), that I don't think that there's much chance
> of them going away.
>
> - Jonathan M Davis

All I can say is that in this case even with UFCS C# enforces parens because it's syntactically clear. Yes, it might be slightly annoying to have to type the (), but that's how you define a function in every other language. A shortcut with side-effects isn't a short-cut, it's a bug factory. And to be honest, once the language spec settles down tools like ReSharper/VisualAssist/etc. can take care of the extra parens. I hand type a small fraction of the parens that actually appear in my C# code.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Thursday, January 24, 2013 22:06:02 mist wrote:
> On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu
> 
> wrote:
> > On 1/24/13 3:58 PM, mist wrote:
> >> Really, all this backwards-compatibility talk is a crap.
> > 
> > There's just a lot of evidence that suggests the contrary. Clearly we don't want or like to be conservative, but apparently we need to.
> > 
> > Andrei
> 
> Do you read and answer only to the first sentence? Can you honestly say "D design is rock solid and correct, we will never be required to make any backwards-incompatible change"?
> 
> If you check those evidences, it was never breaking code alone. It was breaking code AND lack of any sane process that allows to stick with acceptable release version for longer time. And I suggest to fix the right thing, not freeze specs and hope all problems will fade themselves.

The problem is that we have competing goals that we have to deal with

1. Fix any problems in the language so that its design is solid.

2. Avoid breaking people's code.

If we don't do enough of #1, then D will have serious problems, but if we do too much of it, then we'll serious problems because with #2. Even if we end up with the perfect language when we're done, it doesn't matter much if no one's using it, and if we are forever breaking people's code, then they're not going to stick around. The trick is deciding when and how we need to and can get away with breaking code. And the longer it takes to solve major design flaws in the language which require breaking code, the more code we'll break when we do make the changes, and the more problems will have, which is one reason why it's so frustrating that it often takes quite a while to properly sort this sort of thing out.

- Jonathan M Davis

"more extensive processing" does not necessarily involve side effects.

beside that, as long as those side effects only affects the instance owning that property, nothing is wrong about it.

changing a normal member variable could also result in changing the instance's state and behaviour (think that the variable is a flag).

On Thursday, 24 January 2013 at 21:20:01 UTC, Jonathan M Davis wrote:
> We wouldn't have all of these problems if we'd just
> gone with a C#-esque property design

http://msdn.microsoft.com/en-us/library/w86s7x04(v=VS.80).aspx

"To the user of an object, a property appears to be a field, accessing the property requires exactly the same syntax."


Say it with me: properties are DATA FIELDS. Function syntax has NOTHING to do with them!

We could change function syntax to require you to draw out some ASCII art of a running cat.... and it shouldn't affect properties one bit.

Optional parens is a matter of function syntax. Properties are data fields, so function syntax doesn't matter to them.

On Thu, 24 Jan 2013 13:26:11 -0800, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Thursday, January 24, 2013 22:06:02 mist wrote:
>> On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu
>>
>> wrote:
>> > On 1/24/13 3:58 PM, mist wrote:
>> >> Really, all this backwards-compatibility talk is a crap.
>> >
>> > There's just a lot of evidence that suggests the contrary.
>> > Clearly we don't want or like to be conservative, but
>> > apparently we need to.
>> >
>> > Andrei
>>
>> Do you read and answer only to the first sentence? Can you
>> honestly say "D design is rock solid and correct, we will never
>> be required to make any backwards-incompatible change"?
>>
>> If you check those evidences, it was never breaking code alone.
>> It was breaking code AND lack of any sane process that allows to
>> stick with acceptable release version for longer time. And I
>> suggest to fix the right thing, not freeze specs and hope all
>> problems will fade themselves.
>
> The problem is that we have competing goals that we have to deal with
>
> 1. Fix any problems in the language so that its design is solid.
>
> 2. Avoid breaking people's code.
>
> If we don't do enough of #1, then D will have serious problems, but if we do
> too much of it, then we'll serious problems because with #2. Even if we end up
> with the perfect language when we're done, it doesn't matter much if no one's
> using it, and if we are forever breaking people's code, then they're not going
> to stick around. The trick is deciding when and how we need to and can get
> away with breaking code. And the longer it takes to solve major design flaws in
> the language which require breaking code, the more code we'll break when we do
> make the changes, and the more problems will have, which is one reason why
> it's so frustrating that it often takes quite a while to properly sort this
> sort of thing out.
>
> - Jonathan M Davis

I don't think we can fix @property (or remove it) without breaking code. So I would plead with the community to accept that. This is a very important problem to fix.

Obviously deciding how to proceed is going to be difficult but I don't think that we have copious amounts of time for the community to slug it out either. You either break properties or optional parens, either way creates problems.

I would argue that removing @property creates more problems than removing optional parens. One is a highly delicate surgical operation on the parser to handle all the new ambiguities, more documentation to explain, and more chances to the user to D the wrong (but still acceptable) thing, and requires large amounts code refactoring. The other is a simple find/replace in user code, with some simple changes to the parser.

I will always vote for the less bug-prone path. Remove Optional Parens.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return value taking (), the () go on the return value.
>
> 2. the:
>    f = g
> rewrite to:
>    f(g)
> only happens if f is a function that only has overloads for () and (one argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.

What about code that's always ignored @property?


    int delegate() _del;

    int delegate() getDelegate() {
        return _del;
    }

    auto del = getDelegate(); // does _del get called?

Just a thought,
NMS