property / getProperty() / setProperty()

Jarrett Billingsley kb3ctd2 at yahoo.com
Sat Aug 1 09:58:57 PDT 2009


"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*.  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.

> 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. 





More information about the Digitalmars-d mailing list