On 12 April 2010 17:43, Fernando olivero <oliverof@lu.unisi.ch> wrote:
Good idea! I had a similar idea when initially worked on Alien loader.
I think that what is needed also is remove the dependency with the array, i mean explicitly calling the indexes make the image crash if you didn't had the  assumed special object array size.
For example: Â Â Â Â Smalltalk registerSpecialObject: myObject with: aName
    And later you reference that special object by aName instead of an index to the array.
So it would be easier to load/unload the packages that extend the special objects array, because there would be no explicit dependency to indexes.
Yeah, that would be nice. But this will require VM changes.. and therefore is doomed :) Also, this could impact the VM speed significantly, because its using special object quite frequently. Imagine replacing a simple index-based lookup with name(string) based.
Fernando
On Apr 12, 2010, at 4:17 PM, Igor Stasenko wrote:
Hello,
i attempted to load Alien-Core package into trunk image, and it failed.
One of the problem is override of recreateSpecialObjectsArray method..
I wonder, maybe we should design a nicer API for extending/reserving slots in special objects array, so it won't require overriding this method by every package which needs to extend special objects, like FFI or Alien.
Another aspect of replacing this method is , that it makes problematic to unload such package, in case one wants to unload it.
So, my proposal is to add a simple API to SmalltalkImage class, and in order to install additional special objects one should do like:
MyClass class>>initialize
Smalltalk registerSpecialObject: myObject at: 55. Smalltalk registerSpecialObject: myObject at: 56. ...
or:
Smalltalk registerSpecialObjects: #( x y z) startingAt: 56.
upon package unload, a reverse scheme should be supported:
MyClass class>>unload
Smalltalk unregisterSpecialObjectAt: 55. Smalltalk unregisterSpecialObjectAt: 56. ...
or:
Smalltalk unregisterSpecialObjects: 3 startingAt: 56.
what you think?
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.