[squeak-dev] Re: #recreateSpecialObjectsArray woes

Andreas Raab andreas.raab at gmx.de
Mon Apr 12 18:08:09 UTC 2010

On 4/12/2010 10:57 AM, Igor Stasenko wrote:
> On 12 April 2010 20:49, Andreas Raab<andreas.raab at gmx.de>  wrote:
>> Today, you can give your plugin an array of your own special objects that is
>> used by your plugin, registered with the VM as a GC root and there's no need
>> to modify splObjs.
> Looks like i missed something. HOW?
> Suppose a primitive needs to answer an instance of a special class, known by it.
> How it can instantiate it, if it having no any clues, where its
> invoked from, and it can't rely on a receiver, nor any of method's arguments?

You make it work just like splObjs, i.e.,

	"Sets the special objects for my plugin"
	splObjs := interpreterProxy stackObjectValue: 0.
	"... should have sanity checks ..."
	interpreterProxy addGCRoot: (self cCode: '&splObjs').

	"Instantiates a new Bar (at index 2 in the splObjs)"

	"... should have sanity checks ..."
	foo := interpreterProxy instantiateClass: (interpreterProxy 
fetchPointer: 2 ofObject: splObjs) indexableSize: 0.
	interpreterProxy pop: 1 thenPush: foo.

then you use it like here:

Foo class>>startUp: resuming
	"Install my special objects on system startup"
	resuming ifTrue:[
		self primitiveSetSplObjs: {Foo. Bar. DukeNukem. 42}.

Foo class>>newBar
	^self primitiveNewBar

The "trick" is that your plugin can register whatever it wants for GC 
tracing (in fact you should probably set the variable to nilObj and call 
addGCRoot from initialiseModule exactly once and release it via 
shutdownModule). This removes the need for abusing splObjs to stick in 
stuff that you'd like to preserve between prim calls.

   - Andreas

More information about the Squeak-dev mailing list