@property

[Adam D. Ruppe]

On Saturday, 4 August 2012 at 19:08:58 UTC, Jacob Carlborg wrote:
> I don't think that's correct behavior. I think the correct 
> behavior would be to have a property rewrite, something like 
> this:

Yes, I agree in general, but if a getter returns a ref, you should
be able to write to it... I think anyway, but it is an lvalue 
anyway.


What I just added to my hacked compiler is this:

=====
  else if(e1->op == TOKcall) {
             // for property work, if there is a setter, we should 
revert to the older style
             // handling. If not, we can keep it as a CallExp
             CallExp* ce = (CallExp*) e1;
             Expression* temp_e1 = ce->e1;
             if((temp_e1->op == TOKvar && 
temp_e1->type->toBasetype()->ty == Tfunction)) {
                 // this is potentially a setter.... but not 
necessarily
                 fd = ((VarExp 
*)temp_e1)->var->isFuncDeclaration();
                 ethis = NULL;
                 assert(fd);
                 FuncDeclaration *f = fd;
                 Expressions a;
                 a.push(e2);

                 fd = f->overloadResolve(loc, ethis, &a, 1);
                 if (fd && fd->type) {
                     e1 = temp_e1;
                     goto Lsetter;
                 }
             }
=====


To line 10320 - right above where the old style setter code is. 
It isn't perfect yet because it doesn't ensure we are dealing 
with a @property, but it is closer.



The idea is: if we have a setter function, we should try to use 
it, just like dmd does today. If not, we'll leave the call there 
and see what happens. (If it returns ref, it will work, 
otherwise, it errors saying the property is not an lvalue.)


So far this is passing my simple test for assignment, but not yet 
the op assigns.

int a;
@property int funcprop() {
         return a;
}

// setter
@property int funcprop(int s) {
         return a = s + 10;
}

funcprop = 10; // works, funcprop == 20 now
funcprop += 10; // currently does NOT work


> Is rewritten as:
>
> auto __tmp = foo;
> foo = __tmp + 10;

I think this is exactly what we have to do to work in all cases. 
I'm gonna take a look at it next... then it is time to test this 
patch and with a little luck, we can finally put the property 
debate to rest.


> I think that you should always be able to replace a variable 
> with a property. The other way around I'm not so sure. The 
> problem is with methods in classes. Since a method will be 
> virtual by default you can't just replace a property with a 
> variable. That could potentially break subclasses that override 
> the property.

True. I think all the other uses should just work though.