> On 27 Apr 2018, at 21:36, Sean P. DeNigris <s...@clipperadams.com> wrote:
>
> Marcus Denker-4 wrote
>> I will add comments…
>
> I got confused by this again and created an issue:
> https://pharo.manuscript.com/f/cases/21806/Document-Difference-between-ast-and-parseTree
>
> And then Peter Uhnak reminded me on Discord about this thread. I'm happy to
> add the comments, but not sure I understand the issue well enough. IIUC #ast
> is cached, but #parseTree is not. What I don't understand is the purpose of
> this difference and when one would use one over the other.
the cached #ast is for one interesting for speed (that is, in situations where
you ask for it often).
The other use-case is if you want to annotate the AST and keep that annotation
around (till the next
image save, but you can subscribe to ASTCacheReset and re-install the AST in
the cache after cleaning.
(This is used by MetaLinks to make sure they survive image restart).
The last thing that it provides is that we do have a quite powerful mapping
between bytecode/text/context
and the AST. Regardless how you navigate, you get the same object.
e.g. even this one works:
[ 1+2 ] sourceNode == thisContext method ast blockNodes first
> For example,
> when, if ever, would a user want to access a CM's #ast (as opposed to
> #parseTree) and could modifying it create problems?
>
Modification is a problem, yes.. code that wants to modify the AST without
making sure the compiledMethod is in sync later
should use #parseTree.
Code that does not modify the AST (or makes sure to compile it after
modification) is free to use #ast.
or if you want to annotate the AST (which is a modification, after all).
This is not perfect (not at all…) but the simplest solution to get (to some
extend) what you would have if the system would have
a real persistent, first class AST…
To be improved. The ASTCache with it’s naive “lets just cache everything till
the next image save” was done with the idea to see
when it would show that it is too naive… for that it worked amazingly well till
now.
Marcus
