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.
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.
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.
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/
[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
Copyright © 2018 Locksley Creek Software Inc.