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.

Cheers,
   - Andreas

>
> By keeping things intact, we're having a bottleneck which doesn't
> allows developers
> to use a special objects array in their plugins for own purposes (i
> guess you're not
> assuming that FFI and Alien are the only exceptional plugins which
> having an ultimate right to
> touch a special objects array).
>
>> 2) The recreation of the
>> splObjs implies specific knowledge about which values should be added and
>> which values should be removed.
>>
> Sure, each part of a system knows wery well which objects should be
> there and at what place.
> But there is no need to recreate an array (unless it needs to grow) ,
> and it could be done automatically,
> by copying old objects into a new, bigger array, while revoking the
> #recreateSpecialObjects from system completely.
> For replacing an object(s) in array there is a simple as #at:put:
> Ensuring an array size doesn't means automatically that it should be
> rebuilt from scratch, in same way as OrderedCollection
> doesn't forcing you to add all items from scratch into it, once it
> needs to grow.
>
>> In any case, there are only two packages that have ever made mods to the
>> splObjs array (FFI and Alien) for *very* specialized reasons. We should just
>> add these definitions manually and remove the patch from the Alien package.
>>
> I think you are mixing the cause and consequence here. As to me, the
> reason, why there's only two
> plugins who extending a special objects array is because its very
> tedious and error prone.
> Mostly because of conflicting overrides by different packages!
>
> Anyways, if you don't like playing with special objects array. Please,
> can we think of a scheme which at least
> allows us to avoid overrides of a very same method by different packages?
>
>> Cheers,
>>   - Andreas
>>
>
>