On 04/07/07, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> On Wed, 04 Jul 2007 10:09:30 +0200, sig <siguctua at gmail.com> wrote:
>
> > I like it. Now the final question on road to remove globals at all :
> > what you propose to do with these three symbols:
> > #nil
> > #true
> > #false
> > ?
> > And, maybe this is not related problem - what strategy for accessing
> > class of smallint objects, because there's no direct information in
> > smallint object about its class, because its tagged oop, not mem oop
> > in squeak. I know this is mostly a VM responsibility, but still it
> > introduces a limitations: VM must know a sole instance of SmallInteger
> > class and thus it must be global in VM's context (can't say if it
> > global in language context).
> > And also, if nil object represented by machine word, with all bits =
> > 0, its too , can't point to own class directly.
> >
> > I assume, these associations must be held somewhere in Interpreter
> > class, because its a reflection of VM (or smalltalk environment).
>
> Indeed, they are. Inspect (Smalltalk specialObjectsArray). And since it's
> Smalltalk, you can pass your own (0 class) and (nil class) to the VM :)
>
> BTW nil,false,true are associated with their respective bytecode. So
> compiler knows that VM knows how to access objects in (Smalltalk
> specialObjectsArray).
>
Ok, so, instead of having multiple globals tied with VM, we having a
single one - specialObjectsArray.

The reason why i'm asking to a problem which raised when you using
these objects in foreign (Spoon naiads) classes/methods.
Its obvious, that smallint/nils in different images can behave
differently, because anyone can add new methods or modify existing and
then produce code based on these changes.
I'm interesting, what solution Craig proposed to solve this problem.