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