On Mon, Jan 10, 2011 at 12:42 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/1/10 Eliot Miranda <eliot.miranda@gmail.com>:
On Mon, Jan 10, 2011 at 11:42 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Will it work ?
because Compiler class>>new ^ super new parser: self parserClass new
sets the parser ivar with Compiler parserClass new. Maybe you'll need to remove this definition of new too.
I think it works. Behavior>>parser class gets compilerClass parserClass: Behavior>>parserClass "Answer a parser class to use for parsing method headers." ^self compilerClass parserClass So one is supposed to implement a Compiler subclass that defines a class-side parserClass method. e.g. MySpecialClass>>compilerClass ^MySpecialCompiler MySpecialCompiler class>>parserClass ^MySpecialParser So then Compiler>>parserClass ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil:
[parser
class] will also find MySpecialParser. Yes, its heavyweight because the Compiler subclass isn't providing anything other than the reference to the parser. But that's the way the system is written so far. what do you think? best Eliot
I think you are right, the system is like that, and if I remember already was in st80 v2.3. I used this feature, but my CustomCompiler didn't have many methods, mostly #parserClass. So we have a right to question this implementation.
I think the bug is that classes are expected to answer compiler and parser classes, not compiler and parser instances. If things were organized like this: Behavior>parserClass ^Parser Behavior>compilerClass ^Compiler Behavior>newParser ^self parserClass new Behavior>newCompiler ^self compilerClass new parser: self newParser and the compilation utility methods used "self newCompiler" then one could implement just parserClass to obtain the desired effect. What do you think? best Eliot
Nicolas