property / getProperty() / setProperty()

[Ary Borenszweig]

Andrei Alexandrescu escribió:
> Jarrett Billingsley wrote:
>> On Sat, Aug 1, 2009 at 12:21 PM, Andrei
>> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>>> bearophile wrote:
>>>> Andrei Alexandrescu:
>>>>> Thanks. So it looks like get_property() and set_property() could 
>>>>> fly. How
>>>>> does that sound?
>>>> Not too much good. Among the simpler solutions there's the 'property'
>>>> attribute, that while not helping in reducing code (it makes code 
>>>> longer!)
>>>> solves most problems, while being simple. It's the minimal solution 
>>>> that I
>>>> think will work/fly.
>>> We can't throw keywords at problems like they're getting out of 
>>> style. I've
>>> noticed that here every little problem gets solved by a little 
>>> keyword. If
>>> not, some arcane new syntax. Nobody seems to care about rewriting, 
>>> which I
>>> think is best.
>>
>> I don't know if you're just being passive-aggressive here or what.  Is
>> this a response to my post?
>>
>> I'll ask again: do you have any *technical* issues with the 'property'
>> attribute suggestion?
> 
> My main technical issue is throwing a keyword at a very minor issue. 
> Once the keyword is in the mix, we need to define how it interacts with 
> everything else (e.g., are properties overridable?) A solution based on 
> rewrites is considerably simpler and more in according with the size of 
> the problem.

The "property" just signals that the function is a property. But it's 
still a function and all of the previous rules that existed are still valid.

I'll copy Jarrett's points here once more:

1. You can no longer call functions as properties that were never
intended to be (writeln = 4; goes away).
2. The "obj.prop(args)" ambiguity goes away.  *Either* obj.prop is a
normal method function and (args) are passed to it, *or* obj.prop has
the "property" attribute, and (args) are passed to its result.  Stuff
like "obj.prop[i]" is the same way.
3. There is no naming ambiguity.
4. There are no case issues.
5. It provides useful semantic information to tools, IDEs, and reflection.
6. It's nonintrusive and self-documenting.

As you can see, the only thing that will change for users is point 1. 
Nothing else changes, no need to define new rules, new syntax, new 
nothing. It's as unobstrusive as possible (obviusly much better if 
attributes were already present in the language).

About attributes, later I'll write a post about how attribute can be 
started to be implemented (not just the syntax, but what the compiler 
does with them).