On May 1, 2012, at 11:27 AM, Francisco Garau wrote:
Thanks Camilo - I've tried your image with the latest CogVM for Mac and it's usable.
I understand this is work in progress, are you planning to change Object>>instVarAt: with a new primitive? or will that be handled on the image side?
Objects continue to have offset ivars... everything is mapped on those. So #instVarAt: just stays as it is.
Apart from the change in the class declaration, do you think that any of the existing code will have to be changed?
What's the biggest advantage of having slots?
-> Objects describing the layout of a class, simplifying a lot of thing -> Objects describing instance variables, available for reasoning about and e.g annotating. And of course, you can subclass Slot and do special ones... there are examples in the paper. Virtual slots, type check slots, Bit Slot, Property Slot.... http://hal.inria.fr/docs/00/64/17/16/PDF/Verw11b-OOSPLA11-FlexibleObjectLayo...
(and will we also have slots for temp vars?)
Object subclass: #Rectangle layout: PointerLayout slots: { #origin => Slot. #corner => Slot. } classSlots: {} globals: '' category: #'Graphics-Primitives'
Display boundingBox instVarAt: #origin
instVarAt: can not take a symbol, just an integer. And it will return what it finds at the position. In the case of simple slots, there is a 1:1 mapping to iVars and therefore no change. See section 4.1 Primitive Slots "Primitive slots are metaobjects that simply bind an instance variable to a field index." Marcus -- Marcus Denker -- http://marcusdenker.de