On Mon, Jan 10, 2011 at 12:42 PM, Nicolas Cellier < [email protected]> wrote:
> 2011/1/10 Eliot Miranda <[email protected]>: > > > > > > On Mon, Jan 10, 2011 at 11:42 AM, Nicolas Cellier > > <[email protected]> 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 > >
