I would love to have one compilerContext object so that we do not have to pass all these parameters plague It would be nice to have compile: 'text' context: (aCompilerContext) aCompilerContext in: aClass ; silently: true ; inCategory: 'zork' But this is something we should do after :) On Mar 4, 2009, at 10:59 AM, Lukas Renggli wrote:
Hi Jorge,
great to hear. I have two things that I wish you add to your list:
1. My first wish also affects the old compiler, but that should be easy to fix in Pharo. Currently there are dozens of selectors in Behavior that hardcode the currently used compiler #parseClass, #compilerClass, #evaluatorClass, #decompilerClass, #subclassDefinerClass, ... I would prefer to have exactly one entry point, for example under the name #compiler. This object could act like a compiler MOP on the receiving class and set through a preference for all classes of the system that do not override this method themselves. This would make it much cleaner to have different compilers in the image, swap them on the fly, get rid of various hacks and overrides and even allow to unload the old compiler.
2. My second wish is only about the new compiler. One thing stroke me when working on transactional memory and domain specific languages, is that the new compiler isn't as extensible as it advertises. The problem is there is no central place where the different phases (parsing, annotation, bytecode generation) of the compilation is triggered. Currently this happens at various places throughout the system. This has not only the problem that extending the compiler is difficult without patching it, but also makes it nearly impossible to get certain information at a particular place of the process. For example, during parsing it is not know in what class the method is supposed to be compiled, or during bytecode generation I don't know the source code anymore, etc. I suggest to introduce a compilation context, that is accessible anywhere and that can pass necessary information through the compilation phases. Furthermore I suggest to implement the delegation to the different parts of the compiler in a deticated object that can be subclassed and used for example if somebody wants to cleanly replace, customize or extend certain parts of the compiler.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project