Squeakers,<div><br></div><div>Today I learned with Ken Causey's help how to create a SHWorkspace for testing out a custom Parser. And I have to say, the way in which a typical workspace derives which Parser and Compiler class that it uses is rather confused :)</div>
<div><br></div><div>Typically the ParagraphEditor evalutateSelection method determines which parser to use by sending 'class evaluatorClass' to nil. This method is defined in the Behavior class, and simply returns ^ Compiler. The parser is then determined by sending #parserClass to Compiler, which returns ^ Parser. Parser also has a class side method #evaluatorClass which returns ^ Compiler, which is used to instantiate the actual compiler it seems.</div>
<div><br></div><div>To patch your own workspace, it is necessary to subclass whatever workspace you're using and add an instance side method #doItReceiver which returns an instance of whatever parser you want to use: ^ new MyParser. This class has to reference your own compiler class say MyCompiler in its #evalutorClass method, which then must have a #parserClass classide method that refers back to MyParser.</div>
<div><br></div><div>After all of that you can open up your new workspace running your own MyParser and MyCompiler, and program in something not totally dissimilar to Smalltalk.</div><div><br></div><div>Now #evaluatorClass is implemented in 3 places: Behavior, TPureBehavior, and TraitBehavior. And all three have the exact same definition:</div>
<div><br></div><div>^ Compiler</div><div><br></div><div>The method #parserClass is implemented in 9 places, in a few different ways:</div><div><br></div><div>1. Compiler (class side) and MethodNode implement:</div><div><br>
</div><div>^ Parser</div><div><br></div><div>2. Behavior, CompiledMethod, TPureBehavior, and TraitBehavior implements:</div><div><br></div><div>^ compilerClass parserClass </div><div><br></div><div>3. Compiler instance side:</div>
<div><br></div><div>^parser ifNil: [self class parserClass] ifNotNil: [parser class]</div><div><br></div><div>4. UndefinedObject and PseudoClass implement</div><div><br></div><div>^ Compiler parserClass</div><div><br></div>
<div>As you can see, most of the time, it does the right thing, except there are instances where you may actually get the wrong information (such as which parser generated a MethodNode), and there are times when you swap out compilers that don't result in the correct behavior. For example Text>>makeSelectorBold explicitly calls Compiler parserClass which necessarily invokes Parser, not necessarily the parser you're using.</div>
<div><br></div><div>Unmuddying these waters is something I'd love to help out with, but I've found poking around in this region is much like performing open heart surgery on yourself. Sure to kill your image :)</div>
<div><br></div><div>Can anyone shed any light on why the current state of affairs is as it is? It seems like there have been several attempts to make the underpinnings more flexible, allow for "user space" parsers and compilers, but ultimately, it just feels like a sargasso sea, plagued by dragons...</div>
<div><br></div><div>Dave</div><div><br></div><div>-=-=-=-=-=-=-=-=-=-=- <a href="http://blog.dloh.org/">http://blog.dloh.org/</a><br>
</div>