On 11 January 2011 09:14, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
but igor for example in the case of soul, it means that you should load the SoulCompiler which is normal if you want to use soul compiled methods. Now having a reference to a class makes static warning easier than just an object.
From that perspective it doesn't makes any difference: referencing a missing class in #compilerClass, or in #newCompiler would lead to same error/warning.
What makes these approaches different is where you controlling the creation and initialization of compiler instance.
Stef
On Jan 11, 2011, at 12:55 AM, Igor Stasenko wrote:
On 10 January 2011 20:52, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Parser is not hardcoded (except in tests), but parserClass is sometimes sent to the wrong class.. Example is Text>>makeSelectorBold (sent from Debugger) It should be replaced with makeSelectorBoldIn:
Also notice that source code files cannot be analyzed if they contain classes absent from current system that define their own parserClass. That is a problem for change lists, and possibly for MC (it would be interesting to try).
I think that there could be a solution to that. We could require that certain methods like #newParser, #newCompiler should be written in smalltalk. Then code import tools could rely on that and compile these methods first, and then could use them to compile the rest of class'es source code.
Nicolas
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.