Mapping a Slot to an Instance Variable

So how is an instance variable mapped to a Slot Class? The only version of Smalltalk to implement slots into its core is Pharo[1][2][3]. I will compare how the Pharo protocols with the protocols I have introduced in Gemstone/S.

First, lets review how classes are defined in all Smalltalk dialects. The following is a standard class creation method in Pharo. Other dialects have a similar method but it may be slightly different. When this code is evaluated in a workspace, the class will the specified instance variables will be created.

Object subclass: #Person 
	instanceVariablesNames: 'personTitle dateOfBirth gender firstName lastName' 
	classVariablesNames: ''

With the advent of slots, the instance variable name and the slot class must be defined. I will compare how slots are defined in Pharo versus how I have added are defined in Gemstone/S.

Mapping Slot Classes to Instance Variables

  • Pharo
    In Pharo, the following is one way to associate slot classes with the instance variables. The class creation method has the ‘instanceVariableNames:’ section of the creation method has been replaced with a ‘slots:’ section. The ‘slots:’ parameter is a collection composed of key value pairs. Each key value pair is comprised of slot name (instance variable name) and a slot class. The code below is an example of a class creation method in Pharo using slots.

    Object subclass: #Person 
    	slots: {
    		#personTitle => PersonTitleSlot. 
    		#dateOfBirth => DateOfBirthSlot.
    		#gender => GenderSlot.
    		#firstName => FirstNameSlot.
    		#lastName => LastNameSlot. } 
    	classVariables: '' 
    	category: 'xxxx'

    After class creation, slots can be added and removed via the #addSlot: and #removeSlot: methods.

    "The following adds an instance variable slot to Person and then removes it."
    Person addSlot: #eyeColor => EyeColorSlot
    ...
    Person removeSlot: (Person slotNamed: #eyeColor)
  • Gemstone/S
    In Gemstone/S, slots are outside of the core. So the process for mapping slots to the instance variables requires a ‘bolt on’ approach. The following describes how this is achieved.

    First, a place to declare the slot classes is required. Classes that have slots must implement the class method #localSlotDefinitions. This method returns the slot classes which are mapped to the instance variables. The slot class’ slot name must be identical to the instance variable name. An example is that the #defualtSlotName in PersonTitleSlot must be #personTitle. Below is the implementation for Person class.

    Person class>>localSlotDefintions
        ^#(PersonTitleSlot DateOfBirthSlot GenderSlot FirstNameSlot LastNameSlot)

    Because the slots are not in the core, the mapping must be activated. This is done by building a frame model. The frame model is defined as a FrameModel class. An instance of this class contains the mappings between each class and its slot classes. This will be discussed in more detail in another post.

    To add or remove a slot after the frame model is built, the methods #addSlot: and #removeSlotNamed: are provided.

    "The following adds an instance variable slot to Person and then removes it."
    Person addSlot: EyeColorSlot
    ...
    Person removeSlot: (Person slotNamed: #eyeColor)

    If the instance variable does not already exist in the target class, the adding of a slot class to the target class will cause the an instance variable to be added to the class. It is important to note that in Gemstone/S, unlike other Smalltalk implementations, when a class changes shape, a new version of the class is created. The old versions will need to be migrated to the new version.

    Additionally, Gemstone/S also has a concept of a dynamic instance variable. If the dynamic isntance variable is used, then the shape of the class is deemed to not have changed. This is a useful concept for prototyping. A slot class can be defined to use a dynamic instance variable rather than a traditional instance variable.

Conclusions

The implementation of the slots, by necessity, are different at the internal level in Pharo and Gemstone/S. However the concepts are the same. The slot class is the gateway to accessing the contents of the instance variable.

References

[1] http://pharo.org

[2] Marcus Denker, 2013, Advanced Reflection In Smalltalk Slide Presentation

[3] Toon Verwaest, Camillo Bruni, Mircea Lungu, Oscar Nierstrasz. Flexible Object Layouts: enabling lightweight language extensions by intercepting slot access. Proceedings of 26th International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA ’11), Nov 2011, Portland, United States. 2011