Stephen Compall wrote:
Using STCompiler>>#evaluate:parser: in the valueWithUnwind'd block would
also subtly change STFileInParser>>#evaluate:'s meaning -- because
compiler errors wouldn't cause exceptions that could escape the
evaluate: context.
Here's a STCompiler class>>#compile:asMethodOf:classified:parser: (needs
also my previous change to compile:for:classified:parser:) that lets me
load the previously mentioned 'innamespace.st':
compile: methodNode asMethodOf: aBehavior classified: aString parser:
aParser
| compiler |
compiler := self new.
compiler class: aBehavior parser: aParser.
"Usually, when making UndefinedObject methods, you want the
current namespace to be specially added"
aBehavior == UndefinedObject
ifTrue: [compiler addPool: Namespace current].
^(compiler visitNode: methodNode)
methodCategory: aString;
yourself
This version has the advantage of being inconsistent with desired
practice (when compiling methods truly intended for installation within
UndefinedObject), but more consistent than the failure I reported to
start this thread.
However, I am not sure that I wouldn't prefer the semantic change of
putting compilation in the valueWithUnwind (using STCompiler
class>>#evaluate:parser:) or removing it entirely.
Why shouldn't an exception during evaluation by the FileInParser (which
only happens in RBParser>>#parseDoits AFAICS) halt parsing/loading of a
stream without further intervention/resetting by clients of the
FileInParser?
--
Stephen Compall
http://scompall.nocandysw.com/blog
##smalltalk,#gnu-smalltalk on Freenode IRC
_______________________________________________
help-smalltalk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
