Ian,
I am indeed thinking of modifying byte codes for local assignment to invoke
a change tracker. A common strategy that is straightforward in VW & VAST.
A more effective solution than adding the code to setters as you might miss
one, use assignment, ... or perhaps a code maintainer which would find
methods which contain local assignment and ensure change trigger.
Brian
"Ian Bartholomew" <
[hidden email]> wrote in message
news:zqRX8.17441$VP6.1184590@stones...
> Brian,
>
> > Anyone familiar with subclassing the compiler to track changes to
objects
> > under Dolphin?
>
> You will have to be a bit more specific in what you are trying to achieve
> but a few comments...
>
> Dolphin implements it's compiler in a dll so although you could subclass
the
> Compiler class it wouldn't do much good as you would then have to provide
a
> full compiler yourself.
>
> It is possible to get the compiler to generate a modified set of byte
codes
> that facilitate debugging and it _might_ be possible to hook onto
something
> there but (a) it's not easy and (b) probably not what you want anyway.
>
> The easiest way to track when a composite object has changed is to trigger
> events. This normally involves setter methods that trigger a #changed
event
> when called but can be done in other places as needed. Dolphin also
> provides classes (ValueModel etc) that will automatically trigger events
> when changed.
>
> The only difficulty you might have with triggers is if you have used
direct
> accessing of instVars within a class (a debate that we won't start up
again
> please :-)). In this case the RB incorporated into Dolphin XP should make
> reverting to accessor methods a lot less painful.
>
> Regards
> Ian
>
>
>
>
>
>
Locked
