[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Re: STCompiler ignores current namespace change for var

From: Stephen Compall
Subject: [Help-smalltalk] Re: STCompiler ignores current namespace change for var lookup in evals
Date: Tue, 05 Dec 2006 01:47:52 -0600
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: 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 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 '':

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;

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
##smalltalk,#gnu-smalltalk on Freenode IRC

reply via email to

[Prev in Thread] Current Thread [Next in Thread]