>
> So what can we do with this? If you develop a compiler, it is always very
> annoying that any change that you do actually breaks the compiler if you do
> it wrong. Larger changes over multiple methods get quite hard to do.
>
> One thing that we will soon have is the “accept for test” feature that I
> posted recently.
> Another idea is to use the #bindings: feature of the compiler.
>
> I did small experiment, I added this method to the OpalCompiler class on the
> class side:
>
…..
>
> And after that, you can put a #halt deep in the compiler (or do some change
> that needs multiple steps), yet compilation will not be affected.
> Most tests (not all) are writing in a way that they use classes from the
> package directly (they do not go via the global #compilerClass setting).
>
> So this means that one can now change the compiler as much as one wants, test
> it by running tests and then be quite sure that it will not break anything.
>
> Shortcomings:
> -> extensions are not treated, only the main package
> -> Not used much, for sure needs testing to see if this really works.
> -> Can we get rid of the #CompilerOverlay global?
>
I made a pull request:
https://github.com/pharo-project/pharo/pull/1449
Marcus
