On 12 April 2010 20:49, Andreas Raab <andreas.raab@gmx.de> wrote:
On 4/12/2010 10:43 AM, Igor Stasenko wrote:
On 12 April 2010 19:32, Andreas Raab<andreas.raab@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.