[squeak-dev] Re: #recreateSpecialObjectsArray woes

Igor Stasenko siguctua at gmail.com
Mon Apr 12 17:57:16 UTC 2010

On 12 April 2010 20:49, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 4/12/2010 10:43 AM, Igor Stasenko wrote:
>> On 12 April 2010 19:32, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>> On 4/12/2010 7:17 AM, Igor Stasenko wrote:
>>>> what you think?
>>> I think "no, no, no". Two reasons: 1) the extension of the splObjs
>>> implies a
>>> hardcoded contract with the VM; having it externally settable makes it
>>> look
>>> as if one could just stick in stuff for fun.
>> By 'For fun', you mean writing a plugin, which needs own a special
>> objects to work?
> You don't need special objects. Their use in FFI and Alien is a historical
> accident. What you'd do today is register the classes directly with your
> plugin instead of sticking them into splObjs.
>> I wanted to add a special objects couple of times in plugins, but then i
>> had to
>> step back , knowing that it will require overriding the
>> #recreateSpecialObjects
>> method, which is tedious and error prone, because you never know if people
>> who may use your plugin could also use FFI, Alien or something else.
> Precisely. All of these are good reasons why you shouldn't modify splObjs to
> begin with. What you do instead is to provide a primitive in your plugin
> that accepts the classes / objects you intend to use. This wouldn't work in
> the past because you had no way of handling GC correctly.
> 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?

> Cheers,
>  - Andreas

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list