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). Nicolas 2011/1/10 Nicolas Cellier <[email protected]>: > 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. > > Nicolas > > 2011/1/10 Eliot Miranda <[email protected]>: >> >> >> On Mon, Jan 10, 2011 at 9:46 AM, <[email protected]> wrote: >>> >>> Status: Accepted >>> Owner: siguctua >>> >>> New issue 3525 by siguctua: Compiler>>parserClass is broken and does not >>> querying the class for providing the parser class >>> http://code.google.com/p/pharo/issues/detail?id=3525 >>> >>> In the following: >>> >>> Compiler>>parserClass >>> >>> ^parser ifNil: [self class parserClass] ifNotNil: [parser class] >> >> Who writes this stuff ?? ;) >> <blush> >> I suggest the attached: >> parserClass >> ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser >> class] >> >>> >>> 'self class' should actually be 'class parserClass' >>> >>> So, any class could override the default parser by own. In that way a >>> default parser class is answered by Behavior, not by Compiler. >>> A Compiler class>>parserClass is useless. >>> >>> >>> But even more than that, due to initializing 'parser' ivar in >>> Compiler>>new, >>> it never gets to that code, and evaluating 'parser class' >>> So, a class can't specify a custom parser class to compiler. >>> >>> >>> >>> >> >> >
