How to save method parse tree changes?

If I manipulate the parse tree for a method (I'm playing around with my
own refactorings - for fun)

Whats the correct way to write back the changes to the method?

I can ask a node for its methodNode's formatted code (which is a
string) and then I can just set the view's #text

e.g. self view text: node methodNode formattedCode

but this feels a bit hacky -anyone know a better way?

Tim

TimM wrote:
> If I manipulate the parse tree for a method (I'm playing around with my
> own refactorings - for fun)
>
> Whats the correct way to write back the changes to the method?
>
> I can ask a node for its methodNode's formatted code (which is a
> string) and then I can just set the view's #text
>
> e.g. self view text: node methodNode formattedCode

That will just change the text in the browser won't it?  The method
itself will be unchanged until you do an #accept in the browser.

> but this feels a bit hacky -anyone know a better way?

If you want to actually change the method in the Classes
methodDictionary then you will have to recompile it.  That should
automatically update the methods text in any open browser anyway.

YourClass compile: node methodNode formattedCode

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

> If you want to actually change the method in the Classes
> methodDictionary then you will have to recompile it.  That should
> automatically update the methods text in any open browser anyway.
>
> YourClass compile: node methodNode formattedCode
>

Thanks Ian - I have a variation of that working too, i guess I was sort
of hoping that you could ask a node (or at least its methodNode) to
compile. It looks like thats not the case - I'll work out the
incantation and add a loose method.

I guess I'm spoiled really - most things do exactly what you expect and
when they don't you  figure that you must be missing something (and of
course I may still be).

Tim

"TimM" <[hidden email]> wrote in message
news:[hidden email]...
The refactorings act against a model of the system and accumulate a
collection of changes. The changes can then later be applied as an atomic
(from the appoint of undo/redo) unit. This is one of the many elegant
aspects of the design of the Refactory engine.

It's not really a good idea to apply changes directly in the way you are
suggesting, because that would mean losing the ability to test the
refactoring without it actually updating the system, the ability to preview
the effect, and the great support the change objects provide for undo/redo.

In Dolphin6 all changes to the code objects in the image are (or should be)
performed indirectly through change objects so that they are all, as far as
possible, undoable.

Regards

Blair