On May 31, 2013, at 9:04 AM, Norbert Hartl <[email protected]> wrote:
> Sounds great! What happens if a method is recompiled. All metalinks are gone
> then?
>
Yes, because they have no semantic knowledge other than the AST node.
Starting to match trees to put back links is difficult *and* does not work
really, either.
E.g if I put a link
on
self foo.
and then add a second
self foo.
just in front, where will the retained link be?
And them, the new method could be completely different. Maybe the user putting
the link did not want it
on all sends called foo, but on all self sends? No way to tell… they just do
not carry the intention of the developer.
For that one needs higher levels to take care.
The idea is that the links are low-level, you always use them in a managed
way. E.g. a line-based
breakpoint would be manage by the debugger, the links in an AOP system would be
managed by the
PointCut (which declaratively specifies where to put links). Edit method -->
level above puts links again.
In the *long* term I want Pharo to not manipulate text but ASTs directly, in
this case it is easy to maintain the
links as the AST does not change. But this is Pharo5 or so ;-)
But even that does not remove then need of higher levels. Because if the user
put links on all ivar accesses, the
code I add will not magically have those links even in this case, because the
existing do not encode the intention
"I want links on all Ivar access".
Marcus
