On Friday, January 25, 2013 07:14:29 deadalnix wrote:
> On Friday, 25 January 2013 at 05:51:44 UTC, Jonathan M Davis
> 
> wrote:
> > Well, better that then get rid of @property. The other big
> > question is what to
> > do with opDispatch, since unless we add the ability to overload
> > on @property
> > with opDispatch, then it can't work with both properties and
> > non-property
> > functions. Maybe opPropDispatch or somesuch could be introduced
> > to solve that
> > particular problem.
> 
> Can you explain the problem you see with opDispatch ?

If you make opDispatch @property, then you can't use it with normal functions, and if you don't make it @property, then it can't be used with property functions. And you can't overload on @property, so opDispatch is pretty much screwed with regards to properties at this point. It's certainly fixable, but there will need to be a (small) change in the language to do so.

- Jonathan M Davis

On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
> On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu wrote:
> I hate optional parentheses with a passion, but I think that it's quite clear
> that too many people want them (including many who want @property) and that

I hate the optional parentheses (I really see no point for this except in to!"conversions" but that's templates), I want @property to function just like its C# equivalent and I really do not understand why those two issues are so difficult to accept and implement.

On Friday, 25 January 2013 at 06:47:30 UTC, eles wrote:
> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
>> On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu wrote:

Seriously, who wants to try criticizing this?:

http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx

Just provide serious answers why we cannot do that in D.

On Friday, 25 January 2013 at 06:54:15 UTC, eles wrote:
> On Friday, 25 January 2013 at 06:47:30 UTC, eles wrote:
>> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis wrote:
>>> On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu wrote:
>

"Properties have many uses: they can validate data before allowing a change; they can transparently expose data on a class where that data is actually retrieved from some other source, such as a database; they can take an action when data is changed, such as raising an event, or changing the value of other fields."

I think that having *clear* properties in D is worthing.

On Friday, 25 January 2013 at 06:21:59 UTC, Jonathan M Davis wrote:
> If you make opDispatch @property, then you can't use it with normal functions,
> and if you don't make it @property, then it can't be used with property
> functions. And you can't overload on @property, so opDispatch is pretty much
> screwed with regards to properties at this point. It's certainly fixable, but
> there will need to be a (small) change in the language to do so.
>

OK, so opDispatch must definitively be transformed ! I have to say I didn't saw that coming.

It isn't that big of a deal if we consider we rewrite that way :

a.b => a.opDispatch!"b"
a.b!T => a.opDispatch!("b", T)

No need for opDispatch to actually be a function.

According to what is passed as string, opDispatch can resolve itself as a function or a delegate. See example :

class Madness {
    private void function(Madness)[string] fun;

    @property
    auto opDispatch(string name)() {
        immutable f = fun[name];
        return {
            return f(this);
        };
    }
}

A proper inlining mechanism should handle that.

On 01/24/13 21:13, Andrei Alexandrescu wrote:
> On 1/24/13 2:03 PM, Artur Skawina wrote:
>> Trying to make arguments you don't like go away and silencing the messenger is your MO.
> 
> Now that's what's called "ad hominem".

No, it's not - it's just stating the facts; this was not the first such incident.

>> Having said that, I'll elaborate on the sentence you quoted above. See for example Timon's code [1] here: http://dpaste.dzfl.pl/baa538af . Spot the recursion in the tree-walker.
> 
> How about this: insert the parens and then demonstrate how the bug is easier to spot. Wasn't any easier for me.

Bug? In Timon's code? Impossible. :)

No, this is just about syntax. Some functions are not suitable for calling w/o '()',
and the choice needs to stay with the callee. But the distinction is "sane/insane"
for a reason - there's judgment, taste and common sense involved.
Trusting every programmer to get it right won't work, unfortunately.

artur

On Friday, January 25, 2013 07:47:27 eles wrote:
> On Friday, 25 January 2013 at 04:21:07 UTC, Jonathan M Davis
> 
> wrote:
> > On Thursday, January 24, 2013 22:52:36 Andrei Alexandrescu
> > wrote:
> > I hate optional parentheses with a passion, but I think that
> > it's quite clear
> > that too many people want them (including many who want
> > @property) and that
> 
> I hate the optional parentheses (I really see no point for this except in to!"conversions" but that's templates), I want @property to function just like its C# equivalent and I really do not understand why those two issues are so difficult to accept and implement.

The issue is that lots of people like optional parentheses. I expect that even if there were no support for properties in the language whatsoever, the folks who like to be able to elide parens would still like that and want it.

However, even if we're stuck with parenless function calls being legal, we can still have @property function like it does in C# and require that it be used without parens. It's just that many function calls would be able to look like they were getter properties if they're called without parens.

But because of the tons of arguments over @property (many of them really being over parenless function calls rather than @property itself) and the fact that Andrei has never liked the idea of @property in the first place, Walter and Andrei seem to be trying to get rid of it and simplify the language - hence this thread. So, we're forced to argue in favor of @property.

At this point, I think that the best that we can hope for is

1. Parenless function calls will continue to function essentially as they have been.

2. It will be illegal to use a non-@property function as a setter.

3. @property will be kept, and @property functions must be called without parens.

If we go that route, we may also be able to make some improvements to property functions to make them closer to how variables are (e.g. make a.prop += 1 valid), and property functions will be able to be essentially as they are in C# as far as functionality goes, but we'll be stuck with parenless function calls.

- Jonathan M Davis

On 1/25/13 2:12 AM, Artur Skawina wrote:
> On 01/24/13 21:13, Andrei Alexandrescu wrote:
>> On 1/24/13 2:03 PM, Artur Skawina wrote:
>>> Trying to make arguments you don't like go away and silencing the messenger
>>> is your MO.
>>
>> Now that's what's called "ad hominem".
>
> No, it's not - it's just stating the facts; this was not the first such incident.

Of course it is. The definition is simple enough, e.g. from Wikipedia: An ad hominem (Latin for "to the man"), short for argumentum ad hominem, is an argument made personally against an opponent instead of against their argument.

>>> Having said that, I'll elaborate on the sentence you quoted above. See for example
>>> Timon's code [1] here: http://dpaste.dzfl.pl/baa538af . Spot the recursion in the
>>> tree-walker.
>>
>> How about this: insert the parens and then demonstrate how the bug is easier to spot. Wasn't any easier for me.
>
> Bug? In Timon's code? Impossible. :)
>
> No, this is just about syntax. Some functions are not suitable for calling w/o '()',
> and the choice needs to stay with the callee. But the distinction is "sane/insane"
> for a reason - there's judgment, taste and common sense involved.
> Trusting every programmer to get it right won't work, unfortunately.

I'd say "sane/insane" is pushing it.


Andrei

On Friday, 25 January 2013 at 00:12:48 UTC, Andrei Alexandrescu wrote:
> On 1/24/13 6:52 PM, Adam Wilson wrote:
>> On Thu, 24 Jan 2013 00:34:42 -0800, Walter Bright
>> <newshound2@digitalmars.com> wrote:
>
> This looks essentially the same as Walter's proposal.

You overlook that "get/set" in C# are none other than "@property" in D.

So, it is nit Walter's proposal, it is @property proposal.

On 1/25/13 3:10 AM, eles wrote:
> On Friday, 25 January 2013 at 00:12:48 UTC, Andrei Alexandrescu wrote:
>> On 1/24/13 6:52 PM, Adam Wilson wrote:
>>> On Thu, 24 Jan 2013 00:34:42 -0800, Walter Bright
>>> <newshound2@digitalmars.com> wrote:
>>
>> This looks essentially the same as Walter's proposal.
>
> You overlook that "get/set" in C# are none other than "@property" in D.
>
> So, it is nit Walter's proposal, it is @property proposal.

Agreed.

Andrei