On 10 January 2011 22:50, Eliot Miranda <
[hidden email]> wrote:
>
>
> On Mon, Jan 10, 2011 at 12:42 PM, Nicolas Cellier
> <
[hidden email]> wrote:
>>
>> 2011/1/10 Eliot Miranda <
[hidden email]>:
>> >
>> >
>> > On Mon, Jan 10, 2011 at 11:42 AM, Nicolas Cellier
>> > <
[hidden email]> 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?
+1000
i learned that requesting an initialized instance is much more
convenient & flexible than requesting a class just for sending 'new'
to it.
Classes with complex API often don't giving the answer, how properly
initialize its instances, which leads to confusion and inability to
properly connect layers of framework and/or install proper hooks which
in own turn leads to bad coding practices like attempts to control
object initialization outside of its factory (a class, or object which
is really should be responsible for providing it).
In our concrete situation, a #newCompiler message is much more
powerful expression, because it allows a responding object to answer
partially of fully initialized object, and in this way shifting the
responsibility of its initialization to right place.
And in this way, an object which going to answer it, could take care
and properly initialize it, like setting a custom parser.
This is what you can't do by answering classes all the way, since the
only guaranteed protocol of class is a #new message.. Limiting and not
very helpful.
I think that the rule of thumb in all such cases should be following:
- if your code works with objects which implement a certain protocol,
explicitly state that your code requires a preinitialized instance
which comes from other objects, which you communicating with. Never
require any intermediary object(s), because they are actually an
information noise and really should not be a concern of your code.
> best
> Eliot
>>
>> Nicolas
>>
--
Best regards,
Igor Stasenko AKA sig.
Locked
Compiler-parserClass.st (356 bytes)