Am 31.05.2013 um 09:48 schrieb Marcus Denker <[email protected]>:

> 
> 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".

I don't think that editing the AST directly solves this problems. You can 
always remove things in a way so that bringing them back makes you loose the 
meta information. 
But then it maybe is not necessary to put something like that as a AST feature. 
If I programmatically annotate AST nodes I will have some code that does it. 
Then I only need to know when some method has changed and I can reapply the 
annotations/metalinks. To preserve exisiting metalinks I would have to know 
before and after a method has changed so I'm able to reapply the exact same 
thing there. Besides Announcements I could add metalinks to the compiler that 
triggers my code to manage metalinks of my code. There is always a way to go 
meta. Wonderful!

Time for me to make my first 3.0 tests :)

Norbert

Reply via email to