@property - take it behind the woodshed and shoot it?

[Adam D. Ruppe]

On Thursday, 24 January 2013 at 21:44:12 UTC, Adam Wilson wrote:
> From the compilers standpoint they are functions. It must be 
> so. That's how they're implemented.

No, they are @property functions. That's important because it 
lets them be rewritten at the usage point, similarly to operator 
overloading and various other tricks in the language, which also 
doesn't care about function call syntax, despite being 
implemented as functions.


I was messing with the compiler a while ago to make my vision 
work. Got about 90% there, but it got too messy when doing 
setters. Only made 5 changes:

DsymbolExp::semantic

if the function this references was declared as a property, 
rewrite the symbol to be a call expression

Thus "bar", if bar was declared as @property, is rewritten into 
"(bar())" and the rest carries on normally. (So if the whole 
expression was "bar().foo", the rest of the compiler sees it as 
"(bar())().foo" and reacts accordingly.)


DotVarExp::semantic

ditto, but for members instead




And the others were trying to make it work for setters in BinExp, 
AssignExp, and a filthy hack in CallExp itself to find the setter 
given a getter.

The getter change, about 10 lines of code in dmd, was a success. 
The setters are where I tripped up and couldn't get it to work 
right, but this is probably because I'm not a dmd master, not 
because it is impossible.