2009/3/4 Stéphane Ducasse <[email protected]>: > 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 :)
This is something i'm already done in own implementation of parser. I have a context object which role is to respond to such things like silently/interactive, class etc.. > - Show quoted text - > 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
