opOpAssign on object properties

Ivan Kazmenko via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun Jan 8 13:50:12 PST 2017


On Sunday, 8 January 2017 at 18:23:34 UTC, collerblade wrote:
> On Sunday, 8 January 2017 at 10:03:50 UTC, Ivan Kazmenko wrote:
>> On Sunday, 8 January 2017 at 09:22:12 UTC, collerblade wrote:
>>> [...]
>>
>> 1. If you want the member variable to change, naturally, you 
>> should provide a getter property which returns a reference to 
>> that variable:
>>
>> [...]
>
> yes i tried the reference return, but the problem is, that the 
> setter does NOT gets called, no matter what the result type of 
> the opOpAssign method is.
> I want to detect changes, but this way i still not able.
>
> A a = new A;
>
> a.location+=Point(1,1); //the private value changes, but the 
> setter does not get called

Hmm, right.

The setter is not called, and it's by the spec.
Which says that "a op= b" is rewritten as "a.opOpAssign !(op) 
(b)".
Here: https://dlang.org/spec/operatoroverloading.html#op-assign

So, no *assignment* happens when you call a.location+=Point(1,1).
To have a side effect triggered by opAssign-ment, you can do it 
inside the opOpAssign function.

Looking at it another way, actions with struct Point can be seen 
as the responsibility of struct Point.  If you want to monitor 
these actions, do it in the code of opOpAssign function.  After 
that, your class A can inspect the state of its corresponding 
Point.  If normal Points don't need that, you can have a special 
SelfAwarePoint which has an alias this to its member Point.

Alternatively, you can have two getter properties: one as const 
and one by reference.  When the reference one gets called, you 
know the value of Point *may* have changed.

Well, I'm out of ideas for now.  If these still don't quite 
satisfy you, including a bigger picture of what you want to 
achieve may help.

Ivan Kazmenko.



More information about the Digitalmars-d-learn mailing list