new DIP5: Properties 2

[Andrei Alexandrescu]

Jarrett Billingsley wrote:
> On Mon, Jul 27, 2009 at 11:13 PM, Andrei
> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>> Rainer Deyke wrote:
>>> Benji Smith wrote:
>>>> 3) The existence of "magical" identifiers complicates the language
>>>> design. Because the rules that apply to those magical identifiers is
>>>> different than the rules applying to non-magical identifiers.
>>> I don't see how that's the case.  Everywhere opGet_foo appears, it is
>>> treated exactly like every other identifier.
>>>
>>> The only thing "special" about these identifiers is that they can be
>>> generated automatically by the compiler.  When the compiler sees 'a.b',
>>> and 'b' is not a field or method of 'a', it rewrites this to
>>> 'a.opGet_b()'.
>> Oh. You stole my thunder.
>>
>> +1
> 
> While the opGet_foo and opSet_foo are okay, what are your thoughts on
> the 'property' attribute on a function?

My opinion? I'd like to render it unnecessary.

> I know you said you didn't
> really like the idea of having to name your range's empty function
> 'opGet_empty'.

Correct. I'd rather try to disambiguate the rather rare case when a 
property returns a delegate etc. For me, I get a breath of fresh air 
whenever I get to not write "()". I can't figure how some are missing it.

> The property attribute also has the nice property
> (heh) that you can call the property setters and getters either as
> properties or as functions (i.e. "r.empty" or "r.empty()").
> Basically, the behavior would be *exactly* as it is now, except you'd
> have to explicitly state with which functions it would be legal.

I guess I'd rather not have to specify that. I'd do that on all of my 
functions that don't take parameters. To me that's syntactic noise and 
an unnecessary special case.

> Or is the idea of introducing the 'property' keyword too controversial?

In this case the keyword isn't even the largest aggravation. The largest 
aggravation is that everybody is with their hand on the syntactic 
holster when they should look into simplifying and unifying, not adding 
more baroque adornments for what is really some function calls.


Andrei