[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] Re: STCompiler ignores current namespace change for var
[Help-smalltalk] Re: STCompiler ignores current namespace change for var lookup in evals
Tue, 05 Dec 2006 01:47:52 -0600
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124) Gecko/20061030 SeaMonkey/1.0.6
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
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:
| 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)
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
##smalltalk,#gnu-smalltalk on Freenode IRC