On Sun, Mar 18, 2012 at 5:46 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:

What about changing #recreateSpecialObjectsArray so having in mind some classes like Bitmap or Display may not be in the kernel?
This only changes some lines like:

...
�� newArray at: 5 put: (self at: #Bitmap ifAbsent: [ nil ]).

...

�� newArray at: 13 put: (self at: #Point ifAbsent: [ nil ]).

...

�� newArray at: 15 put: (self at:� #Display ifAbsent: [ nil ]).

...

�� newArray at: 34 put: (self at: #Point ifPresent: [ :cls | 0@0] ifAbsent: [ nil ]).

The last one isn't used in Cog (in fact indices 32, 33 & 34 are unused) and probably unused in the Interpreter. �David?

You may be able to get away with making Bitmap and DIsplay optional. �But Point is dug pretty deep into the VM. �Point is used for the special selector send bytecodes for #x, #y & #@. �For #x & #y there's a check that the class of the receiver is Point, and if so, evaluate in-line. �So that is fine; if Point is nil then #x will get sent, rather than evaluated inline. �But if the system sends #@ it'll likely crash, trying to create an object whose class is nil.

To do what you're proposing properly the VM would need to be modified to be safe. �We should perhaps discuss what the right approach is. �e.g. if Point is in fact nil then #x #y and #@ would all slow down slightly in normal use checking for the possibility of Point being nil. �This isn't an issue in Cog since these messages are compiled to regular sends; but t=in the regular interpreter and the StackInterpreter (used on e.g. Android) it may be.

A different approach might be to move these classes to Kernel, or to provide rump classes that raise errors when used, e.g.

newArray at: 13 put: (self at: #Point ifAbsent: [ RumpPoint ]).

(the rump of something being what's left when you take everything away, rump = behind, bottom etc)

Does anyone know if this should this break something?

Guille