property / getProperty() / setProperty()

[Andrei Alexandrescu]

Jarrett Billingsley wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
> news:h51rnq$o2q$1 at digitalmars.com...
>> Jarrett Billingsley wrote:
>>> 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.
> 
> Yeah, it is pretty minor, huh?  I mean, it's not like it's been the center 
> of discussion for the past week.  And no one has ever complained about it 
> before.
> 
> Downplaying the size of the issue at hand doesn't make it go away.
> 
>> Once the keyword is in the mix, we need to define how it interacts with 
>> everything else (e.g., are properties overridable?)
> 
> Of course they're overridable.  They are *functions*.

Then why are you calling them properties? :o)

> They do everything 
> exactly the same as other functions.  *All* the property attribute would do 
> is enforce a property syntax at the use site instead of a function call 
> syntax.

Oh, so it is minor.

>> A solution based on rewrites is considerably simpler and more in according 
>> with the size of the problem.
> 
> A solution based on rewrites has a pretty horrible problem with name 
> ambiguity.  And this isn't even a technical concern; you're just saying 
> again that the problem is minor.  You have not presented any technical 
> arguments against the property attribute suggestion.
> 
> So let me get this straight: the property attribute would be better 
> technically, but let's not throw more keywords at it; so instead we suggest 
> attributes, but no, they don't have any useful purpose.
> 
> WHAT. 

I didn't say that.


Andrei