On May 31, 2013, at 9:04 AM, Norbert Hartl <norbert@hartl.name> 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