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

Slots – An Introduction

This is the first in a series of posts which will discuss the concepts of Frames and Slots and how I have implemented them in Gemstone/S[1] Smalltalk. Gemstone/S is an integrated application server and object database where the language used to access the objects is Smalltalk. It also supports the Seaside[2] web framework.

In this post I will examine what is a slot. Subsequent posts will into more details of Frames and Slots in a Smalltalk environment.

The Problem: Structuring Instance Variable Related Code

Each time a new instance variable is added to a class, the class’ complexity increases. For each added instance variable, a getter and setter method is created. Often the initialization method(s), validation method(s), and other methods are also modified. High number of methods in a class results in reduced code readability, increased testing effort, duplicated code and other artifacts which create or increase the code smell. Adding a slot class to manage the behavior related to an instance variable is one technique to reduce the complexity.

If slot classes also deliver lower coupling and higher cohesion [3] levels then this approach many prove to be very useful.

There have been other solutions for this problem including cross-cutting concerns/aspect-oriented programming (AOP) [4], mixins[5], traits[6], and adaptive-object models [7][8] . This is yet another approach to attempting to add clarity to this problem space.

Where Does The Slot Concept Come From?

Origin Of Frames and Slots

In 1974 Marvin Minsky wrote his seminal paper, ‘A Framework For Representing Knowledge’ [9], which introduced the concepts of ‘Frames’ and ‘Slots’ as the mechanism for representing knowledge.  The Artificial Intelligence community in the 1980’s and early 1990’s research was heavily influenced by these concepts. The result of the research was the development of LISP based languages which also implemented object-oriented concepts that were borrowed from Smalltalk[10].  The Frame and Slot concepts were implemented as classes.  Two branches of LISP, CLOS (Common Lisp Object System) language [11] and Scheme, were developed and both support slots. The R language is a popular descendant Scheme [12].

What is a Slot Class in the context of ‘Frames And Slots’?

Based on the research into Frames and Slots, a consensus of a slot’s behaviour was achieved [13].  The slot class is installed in a Frame class and it has the following properties and behaviors:

  • slot name
  • allowable type(s)
  • allowable values (this can be a validation daemon)
  • default value
  • comment/description
  • attached daemons (processes)
  • the relationship of the object stored in the slot to this frame. This includes the type of relationship and the relationship’s cardinality.
  • the accessing and setting of the object into the frame’s slot is done via an instance of the slot class. Access must flow through the instance of the slot class to ensure that all of the related actions and validations are executed.

In a Frame, the slot refers the to the actual storage location inside the Frame. This is similar to the concept of an instance variable in Smalltalk. However the slot also has the behavior described explicitly associated with it. In Smalltalk, and other object-oriented languages, this explicit association does not exist.

Slot Class In Smalltalk

Based on the work in LISP related languages, a Slot Class in Smalltalk would have the following attributes/behavior

  • slotName
    • this would be the same as the variable name
  • frameClass
    • the class which the slot is associated with. A slot class can be associated with more than one frame class.
  • allowableTypes
    • this is a list of one or more classes that can be stored in the slot (instance variable).
  • initialValue
    • this can be a static value or a block which is evaluated when the frameClass is instantiated
  • relationship
    • specifies the relationship between the object stored in the instance variable and the instance of the frame class. Examples of the types of relationships are Aggregate, Association, NonLinked and Reverse.
  • relatedSlotName
    • this is the name of the slot in the related frame object.
  • cardinality
    • the cardinality of the relationship – 0-1, 1-1, 0-*, 1-*, *-*, etc
  • daemons
    • the daemons are executed in the act of setting or accessing an instance variable. This includes validation, informing dependency, transformations, etc. The daemons can be defined for the following situations, pre-write, post-write, pre-read, post-read

Person Class Example

Assuming a Person class has the following instance variables: personTitle, dateOfBirth, gender, firstName and lastName, then the following slot classes would be created: PersonTitleSlot, GenderSlot, FirstNameSlot and LastNameSlot. Each of these slot classes inherit from the Slot class.

Figure 1 shows the traditional UML class diagram for the instance side of the Person class. There are the five instance variables with their type. Initialization, valiadation and other logic are not shown in this class diagram.

Figure 1: UML Person Class Diagram

With the Slot classes, there is now a new type of relationship which is not covered by the standard UML model. Figure 2 below is an attempt to show that the Person class has a relationship with classes that define the slots. In this diagram it appears that the slot classes are actually meta-data about the instance variable. Is it an extension of the Smalltalk object model? This is an interesting question.

Figure 2: Person class now has relationships with Slot Classes

Finally, Figure 3 is an attempt to model the relationship of the slot classes inside of the Person class. In UML there is a differentiation in modeling attributes which are associations and those which are data types (ex: String, Number, etc). With slots, all are modeled using the same structure.

Figure 3: Modified UML Person Class Diagram with Slot Classes

Summary

I hope that this has given a glimpse about what is a slot, the encapsulation of an instance varaiable’s behavior. Others have thought of it as a wrapper around the instance variable.

I will go into more details in subsequent posts.

References

[1] https://gemtalksystems.com/

[2] http://www.seaside.st

[3] ttps://www.codeproject.com/Articles/898128/Coupling-and-Cohesion

[4] Gregor Kiczales et al. 1997. Aspect-oriented programming. In ECOOP 97 – Object-Oriented Programming, Vol. 1241. Springer, Berlin Heidelberg, 222–241

[5] Gilad Bracha. 1992. THE PROGRAMMING LANGUAGE JIGSAW: MIX-INS, MODULARITY AND MULTIPLE INHERITANCE. Ph.D. Dissertation. Unitversity Of Utah

[6] Stephane Ducasse, Oscar Nierstrasz, Nathanael Scharli, Roel Wuyts, and Andrew P. Black. 2006. Traits: A mechanism for fine-grained reuse. ACM Transactions on Programming Languages and Systems 28, 2 (2006), 331–338

[7] Ayla Dantas, Joseph Yoder, Paulo Borba, and Ralph Johnson. 2004. Using Aspects to Make Adaptive Object-Models Adaptable. In RAMSE’04-ECOOP’04 Workshop on Reflection, AOP, and Meta-Data for Software Evolution. 9–19.

[8] https://adaptiveobjectmodel.com

[9] http://web.media.mit.edu/~minsky/papers/Frames/frames.html

[10] https://en.wikipedia.org/wiki/Smalltalk

[11] https://en.wikipedia.org/wiki/Common_Lisp_Object_System

[12] https://stat.ethz.ch/R-manual/R-devel/library/methods/html/slot.html

[13] Peter D. Karp. 1993. The Design Space of Frame Knowledge Representation Systems. Technical Report 520. SRI International Artificial Intelligence, Menlo Park, CA, USA