> On 09 Jan 2015, at 16:15, Marcus Denker <marcus.den...@inria.fr> wrote:
>
> Hi,
>
> After some searching for a solution… that does not break
> backward-compatibility, I found a way to save classes that use
> slots.
>
> - if a class just uses ivar Slots, it saves it 100% backward compatible (e.g.
> loadable in other systems)
> - if a class uses a special slot or class var, it saves the definition of the
> slot as the variable name in the
> monticello model.
> - on load it checks if there is a space in a variable name, and if yes —>
> decode these as Slot/Global var definions.
> - the code path for non-Slot classes stays largely untouched.
>
> This is not beautiful but backward compatible… you can even load classes with
> Slots in Pharo3, it then creates invalid
> ivar names, which of course means the code does not run but it is readable.
>
> e.g. create a class like
>
> Object subclass: #A
> slots: { #iv => TestSlot }
> classVariables: { }
> category: 'Playground’
>
> (TestSlot is a slot that does not use up space in the instance and instead
> saves the state in the Slot object, which
> means all instances share the state. Just a small example)
>
> Limitations
> -> no support for class variables yet
> -> class instance variables not yet done, either
Class Instance Slots are now done:
https://pharo.fogbugz.com/f/cases/14720
- With this slice
- class definition template for metaclass shows slots when enables
- Metacello loading implemented for class slots
next: Class Variables: add Monticello loading support for class variable
definitions.
Marcus
