A simple reflective object kernel
This book explains the design and the consequence of having a self-described reflective minimal kernel such as ObjVlisp.
Doing so we will learn about objects, object creation instantiation, message lookup, delegation, inheritance and much more.
A class-based reflective minimal kernel
"The difference between classes and objects has been repeatedly emphasized. In the view presented here, these concepts belong to different worlds: the program text only contains classes; at run-time, only objects exist. This is not the only approach. One of the subcultures of object-oriented programming, influenced by Lisp and exemplified by Smalltalk, views classes as object themselves, which still have an existence at run-time." B. Meyer Object-Oriented Software Construction
As this quote expresses it, there is a realm where classes are true objects, instances of other classes. In such systems such as Smalltalk, Pharo, CLOS, classes are described by other classes and form often reflective architectures each one describing the previous level. In this chapter we will explore a minimal reflective class-based kernel, inspired from ObjVlisp . In the following chapter you will implement step by step such a kernel in less than 30 methods.
ObjVlisp
ObjVlisp was published the first time in 1986 when the foundation of object-oriented programming was still emerging . ObjVlisp has explicit metaclasses and supports metaclass reuse. It was inspired from the kernel of Smalltalk-78. The IBM SOM-DSOM kernel is similar to ObjVLisp while implemented in C++ . ObjVlisp is a subset of the reflective kernel of CLOS since CLOS reifies instance variables, generic functions, and method combination . In comparison to ObjVlisp, Smalltalk or Pharo have implicit metaclasses and no metaclass reuse except by basic inheritance but it is more stable as explained by Bouraqadi et al . Studying this kernel is really worth since it has the following properties:
- It unifies class and instances (there is only one data structure to represent all objects, classes included),
- It is composed of only two classes
Class
andObject
(It relies on existing elements such as booleans, arrays, string of the underlying implementation language), - It raises the question of meta-circularity infinite regression (a class is instance of another class that is an instance of yet another class ...) and how to resolve it,
- It forces to revisit allocation, class and object initialization, message passing as well as bootstrap,
- It can be implemented in less than 30 methods in Pharo.
Just remember that this kernel is self-described so we will start to explain some aspects and since everything is linked you may have to read the chapter twice to fully get it.
ObjVLisp's six postulates
The original ObjVlisp kernel is defined by six postulates . Some of them look a bit dated by today standards and the 6th postulate is simply wrong as we will explain later (A solution is simple to design and implement).
Here we report them as stated in the paper for sake of historical perspective.
- An object represents a piece of knowledge and a set of capabilities.
- The only protocol to activate an object is message passing: a message specifies which procedure to apply (denoted by its name, the selector) and its arguments.
- Every object belongs to a class that specifies its data (attributes called fields) and its behavior (procedures called methods). Objects will be dynamically generated from this model, they are called instances of the class. Following Plato, all instances of a class have same structure and shape, but differ through the values of their common instance variables.
- A class is also an object, instantiated by another class, called its metaclass. Consequently (P3), to each class is associated a metaclass which describes its behavior as an object. The initial primitive metaclass is the class Class, built as its own instance.
- A class can be defined as a subclass of one (or many) other class(es). This subclassing mechanism allows sharing of instance variables and methods, and is called inheritance. The class Object represents the most common behavior shared by all objects.
- If the instance variables owned by an object define a local environment, there are also class variables defining a global environment shared by all the instances of a same class. These class variables are defined at the metaclass level according to the following equation: class variable [an-object] = instance variable [an-object’s class].
Kernel overview
If you do not fully grasp the following overview, do not get worry, this full chapter is here to make sure that you will understand it. Let us get started.
Contrary to a real uniform language kernel, ObjVlisp does not consider arrays, booleans, strings, numbers or any other elementary objects as part of the kernel as this is the case in a real bootstrap such as the one of Pharo. ObjVLisp's kernel focuses on understanding Class/Object core relationships.
Figure shows the two core classes of the kernel:
Object
which is the root of the inheritance graph and is instance ofClass
.Class
is the first class and root of the instantiation tree and instance of itself as we will see later.
Figure shows that the class Workstation
is an instance of the class Class
since it is a class and it inherits from Object
the default behavior objects should exhibit. The class WithSingleton
is an instance of the class Class
but in addition it inherits from Class
since this is a metaclass: its instances are classes. As such, it changes the behavior of classes. The class SpecialWorkstation
is an instance of the class WithSingleton
and inherits from Workstation
since its instances exhibits the same behavior as Workstation
.
The two diagrams and will be explained step by step during all this chapter.
The key point to understand such a reflective architecture is that message passing always looks up methods in the class of the receiver of the message and then follows the inheritance chain (See Figure ).
Figure illustrates two main cases:
- When we send a message to
BigMac
orMinna
, the corresponding method is looked up in their corresponding classesWorkstation
orSpecialWorkstation
and follows the inheritance link up toObject
. - When we send a messsage to the classes
Workstation
orSpecialWorkstation
, the corresponding method is looked up in their class, the classClass
up toObject
.
Instances
In this kernel, there is only one instantiation link, it is applied at all the levels as shown by Figure :
- Terminal instances are obviously objects: a workstation named
mac1
is an instance of the classWorkstation
, a point10@20
is instance of the classPoint
. - Classes are also objects instances of other classes: the class
Workstation
is an instance of the classClass
, the classPoint
is an instance of the classClass
.
In our diagrams, we represent objects (mainly terminal instances) as round corner rectangles with the list of instance variable values. Since classes are objects, when we want to stress that classes are objects we use the same graphical convention as shown in Figure .
Handling infinite recursion
A class is an object. Thus it is an instance of another class, its metaclass. This metaclass is an object too, instance of a metametaclass that is an object too instance of another a metametametaclass...... To stop this potential infinite recursion, ObjVlisp uses similar to solutions proposed in many meta circular systems: one instance is instance of itself.
A class is an object. Thus, it is an instance of another class, its metaclass. This metaclass is an object as well, instance of a metametaclass which is itself an instance of another a metametametaclass...
In ObjVLisp:
Class
is the initial class and metaclass,Class
is instance of itself and directly or undirectly all other metaclasses are instances ofClass
.
We will see later the implication of this self instantiation at the level of the class structure itself.
Understanding metaclasses
The model unifies classes and instances. When we follow the instance related postulates of the kernel we get:
- Every object is instance of a class,
- A class is an object instance of a metaclass, and
- A metaclass is only a class that generates classes.
At the implementation level there is only one kind of entity: objects. There is no special treatment for classes. Classes are instantiated following the same process than terminal instances. There are sent messages the same way other objects are sent messages too.
This unification between instances and classes does not mean that we do not distinguish objects and classes.
Indeed not all the objects are classes. In particular, the sole difference between a class and an instance is the ability to respond to the creation message: new
. Only a class knows how to respond to it. Then metaclasses are just classes whose instances are classes as shown in Figure .
Instance structure
The model does not really bring anything new about instance structure when compared with languages such as Pharo or Java.
Instance variables are an ordered sequence of instance variables defined by a class. Such
instance variables are shared by all instances.
The values of such instance variables are specific to each instance.
Figure shows that instances of Workstation
have two values: a name and a next node.
In addition we should note that an object has a pointer to its class. As we will see when we will come to inheritance, every object possesses an instance variable class (inherited from Object
) that points to its class.
Note that this management of class instance variable defined in Object
is specific to the model.
In Pharo for example, the class identification is not managed as a declared instance variable but as an element part of any object. It is an index in a class-table.
About behavior
Let us continue with basic instance behavior. As in modern class-based languages, this kernel has to represent how methods are stored and looked up.
Methods belong to a class. They define the behavior of all the instances of the class. They are stored into a method dictionary that associates a key (the method selector) and the method body.
Since the methods are stored in a class, the method dictionary should be described in the metaclass. Therefore, the method dictionary of a class is the value of the instance variable methodDict
defined on the metaclass Class
. Each class will have its own method dictionary.
Class as an object
Now it is time to ask us about the minimal information that a class should have. Here is the minimal information required:
- A list of instance variables to describe the values that the instances will hold,
- A method dictionary to hold methods,
- A superclass to look up inherited methods.
This minimal state is similar to the one of Pharo: Pharo Behavior
class has a format (compact description of instance variables), method dictionary, and superclass link.
In ObjVLisp, we will had a name so that we can identify the class. As an instance factory, the metaclass Class possesses 4 instance variables that describe a class:
- name the class name,
- superclass its superclass (we limit to single inheritance),
- i-v the list of its instance variables, and
- methodDict a method dictionary.
Since a class is an object. A class possesses the instance variable class
inherited from Object
that refers to its class as any object.
Example: class Point
Figure shows the instance variable values for the class Point
as declared by the programmer and before class initialization and inheritance take place.
- It is an instance of class
Class
: indeed this is a class. - It is named
'Point'
. - It inherits from class
Object
. - It has two instance variables:
x
andy
. After inheritance it will be three instance variables:class
,x
, andy
. - It has a method dictionary.
Example: class Class
Figure describes the class Class
itself. Indeed it is also an object.
- It is an instance of class
Class
: indeed this is a class. - It is named
'Class'
. - It inherits from class
Object
- It has four locally defined instance variables:
name
,superclass
,i-v
, andmethodDict
. - It has a method dictionary.
Everything is an object
Figure describes a typical situation of terminal instances, class and metaclasses when looked at them using an object perspective.
We see three level of instances: terminal objects, instances of Workstation
, Workstation
and Point
classes which are instances of Class
and the metaclass Class
which is instance of itself.
Sending a message
In this kernel, the second postulate states that the only way to perform computation is via message passing.
Sending a message is a two step process as shown by Figure
- Method lookup: the method corresponding to the selector is looked up in the class of the receiver and its superclasses.
- Method execution: the method is applied to the receiver. It means that
self
orthis
in the method will be bound to the receiver.
Conceptually, sending a message can be described by the following function composition:
Method lookup
Now the lookup process is conceptually defined as follows:
- The lookup starts in the class of the receiver.
- If the method is defined in that class (i.e., if the method is defined in the method dictionary), it is returned.
- Otherwise the search continues in the superclass of the currently explored class.
- If no method is found and there is no superclass to explore (if we are in the class
Object
), this is an error.
The method lookup walks through the inheritance graph one class at a time using the superclass link. Here is a possible description of the lookup algorithm that will be used for both instance and class methods.
Handling errors
When the method is not found, the message error
is sent as shown in Figure . Sending a message instead of simply reporting an error using a trace or an exception is a key design decision. It corresponds to the doesNotUnderstand:
message in Pharo and it is an important reflective hook. Indeed classes can define their own implementation of the method error
and perform specific actions in reaction of messages that are not understood. For example, it is possible to implement proxies (objects representing other remote objects) or compile code on the fly by redefining locally such message.
Now it should be noted that the previous algorithm is not really good because in case of error
there can be a mismatch between the number of arguments of the method we are looking for and the
number of arguments of the error
message.
A better way to handle error is to decompose the algorithm differently as follows:
And then we redefined sending a message as follows:
Remarks
This lookup is conceptually the same in Pharo where all methods are public and virtual. There is no statically bound method, even class methods are looked up dynamically. This allows the possibility to define really elegant and dynamic registration mechanism.
While the look up happens at runtime, it is often cached. Languages usually have several systems of caches: one global (class, selector), one per call site.
Inheritance
There are two aspects of inheritance to consider:
- One static for the state where subclasses get superclass state. This instance variable inheritance is static in the sense that it happens only once at class creation time i.e., at compilation-time.
- One dynamic for behavior where methods are looked up during program execution. There the inheritance tree is walked at run-time.
Let's look at these two aspects.
Instance variable inheritance
Instance variable inheritance is done at class creation time and from that perspective static and performed once.
When a class C
is created, its instance variables are the union of the instance variables of its superclass
with the instance variables defined locally in class C
.
Each language defines the exact semantics of instance variable inheritance, for example if they accept instance variables with the same name or not. In our model, we decide to use the simplest way: there should be no name duplicates.
A word about union: when the implementation of the language is based on offsets to access instance variables, the union should make sure that the location of inherited instance variables are kept ordered compared to the superclass because in general we want that methods of the superclass can be applied to subclasses without copying them down and recompiling them. Indeed if a method uses a variable at a given position in the instance variable lists, applying this method to instance of subclasses should work. In the implementation proposed next chapter, we will use accessors and will not support direct access to instance variables from method body.
Method lookup
As previously described in Section , methods are looked up at runtime. Methods defined in superclasses are reused and applied to instances of subclasses. Contrary to instance variable inheritance, this part of inheritance is dynamic, i.e., it happens during program execution.
Object: defining the minimal behavior of any object
Object
represents the minimal behavior that any object should understand. For example, returning the class of an object, being able to handle errors, initializing an object.
This is why Object
is the root of the hierarchy. Depending on language Object
can be complex. In our kernel it is kept minimal as we will show in the implementation chapter.
Figure shows the inheritance graph without the presence of instantiation.
A Workstation is an object (should at least understand the minimal behavior), so the class Workstation
inherits directly or indirectly from the class Object
.
A class is an object (it should understand the minimal behavior) so the class Class
inherits from class Object
. In particular, the class
instance variable is inherited from Object
class.
Remark.
In Pharo, the class Object
is not the root of inheritance. It is ProtoObject
and Object
inherits from it. Most of the classes still inherit from Object
. The design of ProtoObject
is special: the design goal of ProtoObject
is to generate as many as errors as possible. Such errors can be then captured via doesNotUnderstand:
redefinition and can support different scenarios such as proxy implementation.
Inheritance and instantiation together
Now that we saw independently the instantiation and the inheritance graph we can look at the complete picture. Figure shows the graphs and in particular how such graph are used during message resolution:
- the instantiation link is used to find the class where to start to look the method associated with the received message.
- the inheritance link is used to find inherited methods.
This process is also true when we send messages to the classes themselves. There is no difference between sending a message to an object or a class. The system always performs the same steps.
Refresh on self and super semantics
Since our experience showed us that even some book writers got key semantics of object-oriented programming wrong, we just refresh some facts that normally programmers familiar with object-oriented programming should fully master. For further readings refer to Pharo By Example or the Pharo Mooc available at http://mooc.pharo.org.
- self (also called this in languages like Java). self always represents the receiver of the message. The method lookup starts in the class of the receiver.
- super. super always represents the receiver of the message (and not the superclass). The method lookup starts in the superclass of the class containing the super expression (and not in the superclass of the class of the receiver: this would mean that it loops forever in case of inheritance tree of three classes - We let you to find how).
Looking at Figure we see that the key point is that B new bar
returns 50 since
the method is dynamically looked up and self represents the receiver i.e., the instance of the class B
. What is important to see is that self
sends act as a hook and that subclasses code can be injected in superclass code.
For super
, the situation depicted in Figure shows that super
represents the receiver, but that when super
is the receiver of a message, the method is looked up differently (starting from the superclass of the class using super) hence C new bar
returns 100 and not 20 nor 60.
As a conclusion, we can say that self
is dynamic and super
static. Let us explain this view:
- When sending a message to
self
the lookup of the method begins in the class of the receiver.self
is bound at execution-time. We do not know its value until execution time. super
is static in the sense that while the object it will point to is only known at execution time, the place to look for the method is known at compile-time: it should start to look in the class above the one containing super.
Object creation
Now we are ready to understand the creation of objects. In this model there is only one way to create instances: we should send the message new
to the class with a specification of the instance variable values as argument.
Creation of instances of the class Point
The following examples show several point instantiations. What we see is that the model inherits from the Lisp traditional of passing arguments using keys and values, and that the order of arguments is not important.
When there is no value specified, the value of an instance variable is initialized to nil. CLOS provides the notion of default instance variable initialization. It can be added to ObjVlisp as an exercise and does not bring conceptual difficulties.
When the same argument is passed multiple times, then the implementation takes the first occurence.
We should not worry too much about such details: The point is that we can pass multiple arguments with a tag to identify it.
Creation of the class Point instance of Class
Since the class Point
is an instance of the class Class
, to create it, we should send the message new
to the class as follows:
Here what is interesting to see is that we use exactly the same way to create an instance of the class Point
or the class itself. Note that this single way to create objects is supported by the argument variable list.
An implementation could have two different messages to create instances and classes. As soon as the same new
, allocate
, initialize
methods are involved, the essence of the object creation is similar and uniform.
Instance creation: Role of the metaclass
The following diagram (Figure ) shows that against common expectations, when we create a terminal instance the metaclass Class
is evolved in the process. Indeed, we send the message new
to the class, to resolve this message, the system will look for the method in the class of the receiver (here Workstation
) which the metaclass Class
. The method new
is found in the metaclass and applied to the receiver: the class Workstation
. Its effect is to create an instance of the class Workstation
.
The same happens when creating a class. Figure shows the process. We send a message, now this time, to the class Class
. The system makes no exception and to resolve the message, it looks for the method in the class of the receiver. The class of the receiver is itself, so the method new
found in Class
is applied to Class
(since it is the receiver of the message), and a new class is created.
new = allocate and initialize
In fact creating an object is a two step process: Creating an instance is the composition of two actions: memory allocation allocate
message and object initialisation message initialize
.
In Pharo syntax it means:
What we should see is that:
- The message
new
is a message sent to a class. The methodnew
is a class method. - The message
allocate
is a message sent to a class. The methodallocate
is a class method. - The message
initialize:
will be executed on any newly created instance. It means that when it will be sent to a class, a classinitialize:
method will be involved. When it will be sent to a terminal object, an instanceinitialize:
method will be executed (defined inObject
).
Object allocation: the message allocate
Allocating an object means allocating enough space to the object state but not only: it should mark instances with their class name or id. There is a really strong invariant in the model and in general in object-oriented programming model. Every single object must have an identifier to its class else the system will break when trying to resolve a message.
Object allocation should return:
- A newly created instance with empty instance variables (pointing to nil for example).
- But marked with an identifier to its class.
In our model, the marking of an object as instance of a class is performed by setting the value of the instance variable class
inherited from Object
. In Pharo this information is not recorded as a instance variable but encoded in the internal virtual machine object representation.
The allocate
method is defined on the metaclass Class
. Here are some examples of allocation.
A point allocation allocates three slots: one for the class and two for x and y values.
The allocation for an object representing a class allocates six slots: one for class and one for each of the class instance variable: name, super, iv, keywords, and methodDict.
Object initialization
Object initialization is the process to get the values passed as arguments as key/value pair and assigned the value to the corresponding instance variable.
The following snippet illustrates it. An instance of class Point
is created and the key/value pairs (:y 6) and (:x 24) are
specified. The instance is created and it received the initialize:
messages with the key/value pairs.
The initialize:
method is responsible to set the corresponding variables in the receiver.
When an object is initialized as a terminal instance, two actions are performed:
- First we should get the values specified during the creation, i.e., get that y value is 6 and x value is 24,
- Second we should assign the values to the corresponding instance variables of the created object.
Class initialization
During its initialization a class should perform several steps:
- First as any it should get the arguments and assigned them to their corresponding instance variables. This is basically implemented by invoking the
initialize
method ofObject
via a super call sinceObject
is the superclass ofClass
. - Second the inheritance of instance variables should be performed. Before this step the class
iv
instance variable just contains the instance variables that are locally defined. After this step the instance variableiv
will contain all the instance variables inherited and local. In particular this is here that theclass
instance variable inherited fromObject
is added to the instance variables list of the subclass ofObject
. - Third the class should be declared to a class pool or namespaces so that as programmers we can access it via its name.
The Class class
Now we get a better understanding of what is the class Class
.
The class Class
is:
- The initial metaclass and initial class.
- It defines the behavior of all the metaclasses.
- It defines the behavior of all the classes.
In particular, metaclasses define three messages related to instance creation.
- The
new
message creates an initialized instance of the class. It allocates the instance using the class messageallocate
and then initializes it by sending the messageinitialize:
to this instance. - The
allocate
message. As messagenew
it is a class message. It allocates structure for newly created object. - Finally the message
initialize:
. This message has two definitions one onObject
and one onClass
.
There is a difference between the method initialize:
executed on any instance creation and the class initialize:
method only executed when the created instance is a class.
- The first one is a method defined on the class of the object and potentially inherited from
Object
. Thisinitialize:
method just extracts the value corresponding to each instance variables from the argument list and sets them in the corresponding instance variables.
- The class
initialize:
method is executed when a new instance representing a class is executed. The messageinitialize:
is sent to the newly created object but its specialisation for classes will be found during method lookup and it will be executed. Usually this method invokes the default ones because the class parameter should be extracted from the argument list and set in their corresponding instance variables but in addition, instance variable inheritance and class declaration in the class namespace is performed.
Defining a new Metaclass
Now we can study how we can add new metaclasses and see how the system handles them. To create a new metaclass is simple, it is enough to inherit from an existing one. May be this is obvious to you but this is what we will check now.
Abstract
Imagine that we want to define abstract classes. We set the abstractness of a class as the fact that it cannot create instances. To control the creation of instances of a class, we should define a new metaclass which forbids it. Therefore we will define a metaclass whose instances (abstract classes) cannot create instances.
We create a new metaclass named AbstractMetaclass
which inherits from Class
and we redefine the method new
in this metaclass to raise an error (as shown in Figure ). The following code snippet defines this new metaclass.
Two facts describe the relations between this metaclass and the class Class
:
AbstractMetaclass
is a class: It is instance ofClass
.AbstractMetaclass
defines class behavior: It inherits fromClass
.
Now we can define an abstract class Node
.
Sending a message new
to the class Node
will raise an error.
A subclass of Node
, for example Workstation
, can be a concrete class by being an instance of Class
instead of AbstractMetaclass
but still inheriting from Node
. What we see in Figure is that there are two links: instanciation and inheritance and the method lookup follows them as we presented previously: always start in the class of the receiever and follow the inheritance link.
What is key to understand is that when we send the messsage new
to the class Workstation
, we look for methods first in the metaclass Class
. When we send the message new
to class Node
we look in its class: AbstractMetaclass
as shown in Figure . In fact we do what we do for any instances: we look in the class of the receiver.
A class method is just implemented and following the same semantics that instance methods:
Sending the message error
to the class Node
starts in AbstractMetaclass
and since we did not redefine it locally, and it is not found there, the lookup will continue in the superclass of AbstractClass
: the class Class
and then the superclass of class Class
, the class Object
.
About the 6th postulate
The 6th postulate of ObjVLisp is wrong. Let us read it again: If the instance variables owned by an object define a local environment, there are also class variables defining a global environment shared by all the instances of a same class. These class variables are defined at the metaclass level according to the following equation: class variable [an-object] = instance variable [an-object’s class].
It says that class instance variables are equivalent to shared variables between instances and this is wrong. Let us study this. According to the 6th postulate, a shared variable between instances is equal to an instance variable of the class. The definition is not totally clear so let us look at an example given in the article.
Illustrating the problem
Imagine that we would like the constant character '*' to be a class variable shared by all the points of a same class.
We redefine the Point
class as before, but metaclass of which (let us call it MetaPoint
) specifies this common character
For example if a point has a shared variable named char
, this instance variable should be defined in the class of the class Point
called MetaPoint
. The author proposes to define a new metaclass MetaPoint
to hold a new instance variable to represent a shared variable between points.
Then he proposes to use it as follows:
The class Point
can define a method that accesses the character just by going the class level.
So why this is approach is wrong? Because it mixes levels. The instance variable char
is not a class information. It describes the terminal instances and not the instance of the metaclass. Why the metaclass MetaPoint
would need a char
instance variable.
The solution
The solution is that the shared variable char
should be held in a list of the shared variables of the class Point
. Any point instance can access this variable. The implication is that a class should have an extra information to describe it: an instance variable sharedVariable
holding pairs i.e., variable and its value. We should be able to write:
Therefore the metaclass Class
should get an extra instance variable named sharedivs
and each of its instances (the classes Point
, Node
, Object
) can have different values and such values can be shared among their instances by the compiler.
What we see is that sharedivs
is from the Class
vocabulary and we do not need one extra metaclass each time we want to share
a variable. This design is similar to the one of Pharo where a class has a classVariable instance variable holding variable shared in all the subclasses of the class defining it.
Conclusion
We presented a really small kernel composed of two classes Object
root of the inheritance tree and Class
the first metaclass root of the instantiation tree. We revisited all the key points related to method lookup, object and class creation and initialisation. In the subsequent chapter we propose you to implement such kernel.
Further readings
The kernel presented in this chapter is a kernel with explicit metaclasses and as such it is not a panacea. Indeed it raised metaclass composition problems as explained in Bouraqadi et al. excellent article or .
Building a minimal reflective class-based kernel
The objectives of this chapter is to help you to implement step by step the ObjVlisp model explained in the previous chapter. ObjVlisp was designed by P. Cointe who got inspired by the kernel of Smalltalk-78. It has explicit metaclasses and it is composed of two classes Object
and Class
.
Objectives
During the previous chapter, you saw the main points of the ObjVLisp model, now you will implement it. The goals of this implementation are to give a concrete understanding of the concepts presented previously. Here are some of the points you can deeply understand while writing the implementation:
- What is a possible object structure?
- What is object allocation and initialization?
- What is class initialization?
- What the semantics of the method lookup?
- What is a reflective kernel?
- What are the roles of the classes
Class
andObject
? - What is the role of a metaclass?
Preparation
In this section we discuss the set up that you will use, the implementation choices and the conventions that we will follow during all this chapter.
Getting Pharo
You need to download and install Pharo from http://www.pharo.org/. You need a virtual machine, and the couple image and changes. You can use http://get.pharo.org to get a script to download Pharo.
The current version that you can use is Pharo 6.1.
You can use the book Pharo by Example from http://www.pharo.org/PharoByExample/ for an overview of the syntax and the system.
Getting infrastructure definitions
All the necessary definitions are provided as a Monticello package. It contains all the classes, the method categories and the method signatures of the methods that you have to implement. It provides additional functionality such as a dedicated inspector and some extra methods that will make your life easy and help you to concentrate on the essence of the model. It contains also all the tests of the functionality you have to implement.
To load the code, execute the following expression:
Alternatively, to load the code open a monticello browser,
- Add a file repository to point to an ObjVLispSkeleton project under
StephaneDucasse
in the ObjVLispSkeleton project at http://www.smalltalkhub.com. Use the following expression in the smalltalkhub repository creation pop up.
- Select the latest file and load it.
Running tests
For each functionality you will have to run some tests.
For example to run a particular test named testPrimitive
,
- evaluate the following expression
(ObjTest selector: #testPrimitiveStructure) run
or - click on the icon of the method named
testPrimitiveStructure
.
Note that since you are developing the kernel, to test it we implemented manually some mocks of the classes and kernel. This is the setup method of the test classes that build this fake kernel. Now pay attention because the setups are often taking shortcuts, so do not copy them blindly.
Naming conventions
We use the following conventions: we name as primitives all the Pharo methods that participate in the building of ObjVLisp. These primitives are mainly implemented as methods of the class Obj
. Note that in a Lisp implementation such primitives would be just lambda expressions, in a C implementation such primitives would be represented by C functions.
To help you to distinguish between classes in the implementation language (Pharo) and the ObjVLisp model, we prefix all the ObjVLisp classes by Obj
. Finally, some of the crucial and confusing primitives (mainly the class structure ones) are all prefixed by obj
. For example the primitive that given an objInstance returns its class identifier is named objClassId
.
We also talk about objInstances, objObjects and objClasses to refer to
specific instances, objects or classes defined in ObjVLisp.
Inheriting from class Array
We do not want to implement a scanner, a parser and a compiler for ObjVLisp but concentrate on the essence of the language. That's why we chose to use as much as possible the implementation language, here Pharo. As Pharo does not support macro definition, we will use as much as possible the existing classes to avoid extra syntactic problems.
In our implementation, every object in the ObjVLisp world is instance of the class Obj
.
The class Obj
is a subclass of Array
.
Since Obj
is a subclass of Array
, #(#ObjPoint 10 15)
is an objInstance of the class ObjPoint
which is also an array instance of the Pharo class ObjClass
.
As we will see:
#(#ObjPoint 10 15)
represents an objPoint (10,15). It is an objInstance of the classObjPoint
.#(#ObjClass #ObjPoint #ObjObject #(class x y) #(:x :y) nil )
is the array that represents the objclassObjPoint
.
About representation choices
You can skip this discussion in a first reading. We could have implemented ObjVLisp functionality at the class level of a class named Obj
inheriting simply from Object
. However, to use the ObjVlisp primitive (a Pharo method) objInstanceVariableValue: anObject for: anInstanceVariable
that returns the value of the instance variable in anObject
, we would have been forced to write the following expression:
We chose to represent any ObjVLisp object by an array and to define the ObjVLisp functionality in the instance side of the class Obj
(a subclass of Array
). That way we can write in a more natural and readable way the previous functionality as:
Facilitating objclass class access
We need a way to store and access ObjVLisp classes. As a
solution, on the class level of the Pharo class Obj
we defined a
dictionary holding the defined classes. This dictionary acts as the namespace for our language. We defined the following methods to store and access defined classes.
declareClass: anObjClass
stores the objinstanceanObjClass
given as argument in the class repository (here a dictionary whose keys are the class names and values the ObjVLisp classes themselves).
giveClassNamed: aSymbol
returns the ObjVLisp class namedaSymbol
if it exists. The class should have been declared previously.
With such methods we can write code like the following one that looks for the class of the class ObjPoint
.
To make class access less heavy, we also implemented a shortcut:
We trap messages not understood sent to Obj
and look into the defined class dictionary.
Since ObjPoint
is an unknown message, this same code is then written as:
Now you are ready to start.
Structure and primitives
The first issue is how to represent objects. We have to agree on an initial representation. In this implementation we chose to represent the objinstances as arrays (instances of Obj
a subclass of Array
). In the following we use the terms array for talking about instances of the class Obj
.
Your job.
Check that the class Obj
exists and inherits from Array
.
Structure of a class
The first object that we will create is the class ObjClass
. Therefore we
focus now on the minimal structure of the classes in our language.
An objinstance representing a class has the following structure: an identifier to its class, a name, an identifier to its superclass (we limit the model to single inheritance), a list of instance variables, a list of initialization keywords, and a method dictionary.
For example the class ObjPoint
has then the following structure:
It means that ObjPoint
is an instance of ObjClass
, is named #ObjPoint
, inherits from a class named ObjObject
, has three instance variables, two initialization keywords and an uninitialized method dictionary. To access this structure we define some primitives as shown in Figure .
Your job.
The test methods of the class RawObjTest
that are in the categories 'step1-tests-structure of objects'
and 'step2-tests-structure of classes'
give some examples of structure accesses.
Figure shows how offsets are used to access in an controlled manner the raw objclass information.
Implement the primitives that are missing to run the following tests testPrimitiveStructureObjClassId
,
testPrimitiveStructureObjIVs
, testPrimitiveStructureObjKeywords
,
testPrimitiveStructureObjMethodDict
, testPrimitiveStructureObjName
, and testPrimitiveStructureObjSuperclassId
.
You can execute them by selecting the following expression (RawObjTest selector:
#testPrimitiveStructureObjClassId) run
. Note that arrays start at 1 in Pharo. Below is the list of the primitives that you should implement.
Implement in protocol 'object structure primitives'
the primitives that manage:
- the class of the instance represented as a symbol.
objClassId
,objClassId: aSymbol
. The receiver is anobjObject
. This means that this primitive can be applied on any objInstances to get its class identifier.
Implement in protocol 'class structure primitives'
the primitives that manage:
- the class name:
objName
,objName: aSymbol
. The receiver is an objClass. - the superclass:
objSuperclassId
,objSuperclassId: aSymbol
. The receiver is an objClass. - the instance variables:
objIVs
,objIVs: anOrderedCollection
. The receiver is an objClass. - the keyword list:
objKeywords
,objKeywords: anOrderedCollection
. The receiver is an objClass. - the method dictionary:
objMethodDict
,objMethodDict: anIdentityDictionary
. The receiver is an objClass.
Finding the class of an object
Every object keeps the identifier of its class (its name). For example an instance of ObjPoint
has then the following structure: #(#ObjPoint 10 15)
where #ObjPoint
is a symbol identifying the class ObjPoint
.
Your job.
Using the primitive giveClassNamed: aSymbol
defined at the class level of Obj, define the primitive objClass
in the protocol 'object-structure primitive'
that returns the objInstance that represents its class (Classes are objects too in ObjVLisp).
Make sure that you execute the test method: testClassAccess
Now we will be ready to manipulate objInstances via proper API. We will now use the class ObjTest
for more elaborated tests.
Accessing object instance variable values
A first simple method.
The following test illustrate the behavior of the message offsetFromClassOfInstanceVariable:
Your job.
In the protocol 'iv management'
define a method called offsetFromClassOfInstanceVariable: aSymbol
that returns the offset of the instance variable represented by the symbol given in parameter. It returns 0 if the variable is not defined. Look at the tests #testIVOffset
of the class ObjTest
.
Hints: Use the Pharo method indexOf:
. Pay attention that such a primitive is applied to an objClass as shown in the test.
Make sure that you execute the test method: testIVOffset
A second simple method.
The following test illustrates the expected behavior
Your job.
Using the preceeding method, define in the protocol 'iv management'
- the method
offsetFromObjectOfInstanceVariable: aSymbol
that returns the offset of the instance variable. Note that this time the method is applied to an objInstance presenting an instance and not a class (as shown in Figure ). - the method
valueOfInstanceVariable: aSymbol
that returns the value of this instance variable in the given object as shown in the test below.
Note that for the method offsetFromObjectOfInstanceVariable:
you can check that the instance variable exists in the class of the object and else raise an error using the Pharo method error:
.
Make sure that you execute the test method: testIVOffsetAndValue
and it passes.
Object allocation and initialization
The creation of an object is the composition of two elementary operations: its 'allocation' and its initialization.
We now define all the primitives that allow us to allocate and initialize an object. Remember that
- the allocation is a class method that returns a nearly empty structure, nearly empty because the instance represented by the structure should at least knows its class and
- the initialization of an instance is an instance method that given a newly allocated instance and a list of initialization arguments fill the instance.
Instance allocation
As shown in the class ObjTest
, if the class ObjPoint
has two instance variables: ObjPoint allocateAnInstance
returns #(#ObjPoint nil nil)
.
Your job.
In the protocol 'instance allocation'
implement the primitive called allocateAnInstance
that sent to an objClass returns a new instance whose instance variable values are nil and whose objClassId represents the objClass.
Make sure that you execute the test method: testAllocate
Keywords primitives
The original implementation of ObjVLisp uses the facility offered by the Lisp keywords to ease the specification of the instance variable values during instance creation. It also provides an uniform and unique way to create objects. We have to implement some functionality to support keywords. However as this is not really interesting that you lose time we give you all the necessary primitives.
Your job.
All the functionality for managing the keywords are defined into the protocol 'keyword management'
. Read the code and the associated test called testKeywords
in the class ObjTest
.
Make sure that you execute the test method: testKeywords
and that it passes.
Object initialization
Once an object is allocated, it may be initialized by the programmer by specifying a list of initialization values. We can represent such list by an array containing alternatively
a keyword and a value like #(#toto 33 #x 23)
where 33 is associated with #toto
and 23 with #x
.
Your job.
Read in the protocol 'instance initialization'
the primitive initializeUsing: anArray
that sent an object with an initialization list returns an initialized object.
Static inheritance of instance variables
Instance variables are statically inherited at the class creation time. The simplest form of instance variable inheritance is to define the complete set of instance variables as the ordered fusion between the inherited instance variables and the locally defined instance variables. For simplicity reason and as most of the languages, we chose to forbid duplicated instance variables in the inheritance chain.
Your job.
In the protocol 'iv inheritance'
, read and understand the primitive computeNewIVFrom: superIVOrdCol with: localIVOrdCol
.
The primitive takes two ordered collections of symbols and returns an ordered collection containing the union of the two ordered collections but with the extra constraint that the order of elements of the first ordered collection is kept. Look at the test method testInstanceVariableInheritance
below for examples.
Make sure that you execute the test method: testInstanceVariableInheritance
and that is passes.
Side remark
You could think that keeping the same order of the instance variables between a superclass and its subclass is not an issue. This is partly true in this simple implementation because the instance variable accessors compute each time the corresponding offset to access an instance variable using the primitive offsetFromClassOfInstanceVariable:
. However, the structure (instance variable order) of a class is hardcoded by the primitives. That's why your implementation of the primitive computeNewIVFrom:with:
should take care of that aspect.
Method management
A class stores the behavior (expressed by methods) shared by all its instances into a method dictionary. In our implementation, we represent methods by associating a symbol to a Pharo block a kind of anonymous method. The block is then stored in the method dictionary of an objClass.
In this implementation we do not offer the ability to access directly instance variables of the class in which the method is defined. This could be done by sharing a common environment among all the methods. The programmer has to use accessors or the setIV
and getIV
objMethods defined on ObjObject
to access the instance variables. You can find the definition of such methods in the bootstrap method on the class side of Obj
.
In our ObjVLisp implementation, we do not have a syntax for message passing. Instead we call the primitives using the Pharo syntax for message passing (using the message send:withArguments:
).
The following expression objself getIV: x
is expressed in ObjVLisp as
objself send: #getIV withArguments: #(#x)
.
The following code describes the definition of the accessor method x
defined on the objClass ObjPoint
that invokes a field access using the message getIV
.
As a first approximation this code will create the following block that will get stored into the class method dictionary. [ :objself | objself send: #getIV withArguments: #(#x) ]
. As you may notice, in our implementation, the receiver is always an explicit argument of the method. Here we named it objself
.
Defining a method and sending a message
As we want to keep this implementation as simple as possible, we define only one primitive for sending a message: it is send:withArguments:
. To see the mapping between Pharo and ObjVlisp ways of expressing message sent, look at the comparison below:
While in Pharo you would write the following method definition:
In our implementation of ObjVlisp you write:
Your job.
We provide all the primitives that handle with method definition. In the protocol 'method management'
look at the methods addMethod: aSelector args: aString withBody: aStringBlock
,
removeMethod: aSelector
and doesUnderstand: aSelector
. Implement bodyOfMethod: aSelector
.
Make sure that you execute the test method: testMethodManagement
Message passing and dynamic lookup
Sending a message is the result of the composition of method lookup and execution. The following basicSend:withArguments:from:
primitive just implements it.
First it looks up the method into the class or superclass of the receiver then if a
method has been found it execute it, else lookup:
returned nil and we raise a Pharo error.
Based on this primitive we can express send:withArguments:
and super:withArguments:
as follows:
Method lookup
The primitive lookup: selector
applied to an objClass
should return the method associated to the selector if it found it, else nil to indicate that it failed.
Your job.
Implement the primitive lookup: selector
that sent to an objClass with a method selector, a symbol and the initial receiver of the message, returns the method-body of the method associated with the selector in the objClass or its superclasses. Moreover if the method is not found, nil is returned.
Make sure that you execute the test methods: testNilWhenErrorInLookup
and testRaisesErrorSendWhenErrorInLookup
whose code is given below:
Managing super
To invoke a superclass hidden method, in Java and Pharo you use super
, which means that the lookup up will start above the class defining the method containing the super expression. In fact we can consider that in Java or Pharo, super is a syntactic sugar to refer to the receiver but changing where the method lookup starts. This is what we see in our implementation where we do not have syntactic support.
Let us see how we will express the following situation.
In our implementation of ObjVlisp we do not have a syntactic construct to express super, you have to use the super:withArguments:
Pharo message as follows.
Note that superClassOfClassDefiningTheMethod
is a variable that is bound to the superclass of anObjClass
i.e., the class defining the method bar
(see later).
Representing super
We would like to explain you where the superClassOfClassDefiningTheMethod
variable comes from.
When we compare the primitive send:withArguments:
, for super sends we added a third parameter to the primitive and we called it super:withArguments:from:
.
This extra parameter corresponds to the superclass of class in which the method is defined. This argument should always have the same name, i.e., superClassOfClassDefiningTheMethod
. This variable will be bound when the method is added in the method dictionary of an objClass.
If you want to understand how we bind the variable, here is the explanation:
In fact, a method is not only a block but it needs to know the class that defines it or its superclass. We added such information using currification. (a currification is the transformation of a function with n arguments into function with less argument but an environment capture: f(x,y)= (+ x y)
is transformed into a function f(x)=f(y)(+ x y)
that returns a function of a single argument y and where x is bound to a value and obtain a function generator). For example, f(2,y)
returns a function f(y)=(+ 2 y)
that adds its parameter to 2. A currification acts as a generator of function where one of the argument of the original function is fixed.
In Pharo we wrap the block representing the method around another block with a single parameter and we bind this parameter with the superclass of the class defining the method. When the method is added to the method dictionary, we evaluate the first block with the superclass as parameter as illustrated as follows:
So now you know where the superClassOfClassDefiningTheMethod
variable comes from.
Make sure that you execute the test method: testMethodLookup
and that is passes.
Your job.
Now you should be implement super: selector withArguments: arguments from: aSuperclass
using the primitive basicSend:withArguments:from:
.
Handling not understood messages
Now we can revisit error handling. Instead of raising a Pharo error, we want to send an ObjVlisp message to the receiver of the message to give him a chance to trap the error.
Compare the two following versions of basicSend: selector withArguments: arguments from: aClass
and propose an implementation of sendError: selector withArgs: arguments
.
It should be noted that the objVlisp method is defined as follows in the ObjObject
class (see the bootstrap method on the class side of Obj). The obj error
method expects a single parameter: an array of arguments whose first element is the selector of the not understood message.
Make sure that you read and execute the test method: testSendErrorRaisesErrorSendWhenErrorInLookup
.
Have a look at the implementation of the #error
method defined in ObjObject
and in the assembleObjectClass
of the ObjTest class.
Bootstrapping the system
Now you have implemented all the behavior we need, you are ready to bootstrap the system: this means creating the kernel consisting of ObjObject
and ObjClass
classes from themselves. The idea of a smart bootstrap is to be as lazy as possible and to use the system to create itself by creating fast a fake but working first class with which we will build the rest.
Three steps compose the ObjVlisp bootstrap,
- we create by hand the minimal part of the objClass
ObjClass
and then - we use it to create normally
ObjObject
objClass and then - we recreate normally and completely
ObjClass
.
These three steps are described by the following bootstrap method of Obj class. Note the bootstrap is defined as class methods of the class Obj.
To help you to implement the functionality of the objClasses ObjClass
and
ObjObject
, we defined another set of tests in the class ObjTestBootstrap
.
Read them.
Manually creating ObjClass
The first step is to create manually the class ObjClass
. By manually we mean create an array (because we chose an array to represent instances and classes in particular) that represents the objClass ObjClass
, then define its methods. You will implement/read this in the primitive manuallyCreateObjClass
as shown below:
For this purpose, you have to implement/read all the primitives that compose it.
Your job.
At the class level in the protocol 'bootstrap objClass manual'
read or implement:
the primitive manualObjClassStructure
that returns an objObject that represents the class ObjClass
.
Make sure that you execute the test method: testManuallyCreateObjClassStructure
- As the
initialize
of this first phase of the bootstrap is not easy we give you its code. Note that the definition of the objMethodinitialize
is done in the primitive methoddefineManualInitializeMethodIn:
.
Note that this method works without inheritance since the class ObjObject
does not
exist yet.
The primitive defineAllocateMethodIn: anObjClass
defines in anObjClass passed as argument the objMethod allocate
. allocate
takes only one argument: the class for which a new instance is created as shown below:
Following the same principle, define the primitive defineNewMethodIn: anObjClass
that defines in anObjClass passed as argument the objMethod new
. new
takes two arguments: a class and an initargs-list. It should invoke the objMethod allocate
and initialize
.
Your job.
Make sure that you read and execute the test method: testManuallyCreateObjClassAllocate
Remarks
Read carefully the following remarks below and the code.
- In the objMethod
manualObjClassStructure
, the instance variable inheritance is simulated. Indeed the instance variable array contains#class
that should normally be inherited fromObjObject
as we will see in the third phase of the bootstrap.
- Note that the class is declared into the class repository using the method
declareClass:
.
- Note the method
#initialize
is method of the metaclassObjClass
: when you create a class the initialize method is invoked on a class! Theinitialize
objMethod defines onObjClass
has two aspects: the first one dealing with the initialization of the class like any other instance (first line). This behavior is normally done using a super call to invoke theinitialize
method defined inObjObject
. The final version of theinitialize
method will do it using perform. The second one dealing with the initialization of classes: performing the instance variable inheritance, then computing the keywords of the newly created class. Note in this final step that the keyword array does not contain the#class:
keyword because we do not want to let the user modify the class of an object.
Creation of ObjObject
Now you are in the situation where you can create the first real and normal class of the system: the class ObjObject
. To do that you send the message new
to class ObjClass
specifying that the class you are creating is named #ObjObject
and
only have one instance variable called class
. Then you will add the methods defining the behavior shared by all the objects.
Your job: objObjectStructure
Implement/read the following primitive objObjectStructure
that creates the ObjObject
by invoking the new
message to the class ObjClass
:
The class ObjObject
is named ObjObject
, has only one instance variable class
and does not have a superclass because it is the inheritance graph root.
Your job: createObjObject
Now implement the primitive createObjObject
that calls objObjectStructure
to obtain the objObject
representing
objObject
class and define methods in it. To help you we give here the beginning of such a method
Implement the following methods in ObjObject
- the objMethod
class
that given an objInstance returns its class (the objInstance that represents the class). - the objMethod
isClass
that returns false. - the objMethod
isMetaClass
that returns false. - the objMethod
error
that takes two arguments the receiver and the selector of the original invocation and raises an error. - the objMethod
getIV
that takes the receiver and an attribute name, aSymbol, and returns its value for the receiver. - the objMethod
setIV
that takes the receiver, an attribute name and a value and sets the value of the given attribute to the given value. - the objMethod
initialize
that takes the receiver and an initargs-list and initializes the receiver according to the specification given by the initargs-list. Note that here theinitialize
method only fill the instance according to the specification given by the initargs-list. Compare with theinitialize
method defined onObjClass
.
Make sure that you read and execute the test method: testCreateObjObjectStructure
In particular notice that this class does not implement the class method new
because it is not a metaclass but does implement the instance method initialize
because any object should be initialized.
Your job: run the tests
- Make sure that you read and execute the test method:
testCreateObjObjectMessage
- Make sure that you read and execute the test method:
testCreateObjObjectInstanceMessage
Creation of ObjClass
Following the same approach, you can now recreate completely the class ObjClass
. The primitive createObjClass
is responsible to create the final class ObjClass
. So you will implement it and define all the primitive it needs. Now we only define what is specific to classes, the rest is inherited from the superclass of the class ObjClass
, the class ObjObject
.
To make the method createObjClass
working we should implement the method it calls. Implement then:
- the primitive
objClassStructure
that creates theObjClass
class by invoking thenew
message to the classObjClass
. Note that during this method theObjClass
symbol refers to two different entities because the new class that is created using the old one is declared in the class dictionary with the same name.
Your job.
Make sure that you read and execute the test method: testCreateObjClassStructure
.
Now implement the primitive createObjClass
that starts as follow:
Also define the following methods:
- the objMethod
isClass
that returns true. - the objMethod
isMetaclass
that returns true.
- the primitive
defineInitializeMethodIn: anObjClass
that adds the objMethodinitialize
to the objClass passed as argument. The objMethodinitialize
takes the receiver (an objClass) and an initargs-list and initializesthe receiver according to the specification given by the initargs-list. In particular, it should be initialized as any other object, then it should compute its instance variable (i.e., inherited instance variables are computed), the keywords are also computed, the method dictionary should be defined and the class is then declared as an existing one. We provide the following template to help you.
Your job.
Make sure that you execute the test method: testCreateObjClassMessage
.
Note the following points:
- The locally specified instance variables now are just the instance variables that describe a class. The instance variable
class
is inherited fromObjObject
. - The
initialize
method now does a super send to invoke the initialization performed byObjObject
.
First User Classes: ObjPoint
Now that ObjVLisp is created and we can start to program some classes.
Implement the class ObjPoint
and ObjColoredPoint
. Here is a possible implementation.
You can choose to implement it at the class level of the class Obj or even better in class named ObjPointTest
.
Pay attention that your scenario covers the following aspects:
- First just create the class
ObjPoint
. - Create an instance of the class
ObjPoint
. - Send some messages defined in
ObjObject
to this instance.
Define the class ObjPoint
so that we can create points as below (create a Pharo method to define it).
Then add some functionality to the class ObjPoint
like the methods x
, x:
, display
which prints the receiver.
Then test these new functionality.
First User Classes: ObjColoredPoint
Following the same idea, define the class ObjColored
.
Create an instance and send it some basic messages.
Your job.
Define some functionality and invoke them: the method color, implement the method display so that it invokes the superclass and adds some information related to the color. Here is an example:
A First User Metaclass: ObjAbstract
Now implement the metaclass ObjAbstract
that defines instances (classes) that are abstract i.e., that
cannot create instances. This class should raise an error when it executes the new
message.
Then the following shows you a possible use of this metaclass.
You should redefine the new
method. Note that the ObjAbstractClass
is an instance of ObjClass
because this is a class and inherits from it because this is a metaclass.
New features that you could implement
You can implement some simple features:
- define a metaclass that automatically defines accessors for the specified instances variables.
- avoid that we can change the selector and the arguments when calling a super send.
Shared Variables
Note that contrary to the proposition made in the 6th postulate of the original ObjVLisp model, class instance variables are not equivalent of shared variables. According to the 6th postulate, a shared variable will be stored into the instance representing the class and not in an instance variable of the class representing the shared variables. For example if a workstation has a shared variable named domain
. But domain should not be an extra instance variable of the class of Workstation
. Indeed domain has nothing to do with class description.
The correct solution is that domain
is a value hold into the list of the shared variable of the class Workstation
. This means that
a class has an extra information to describe it: an instance variable sharedVariable
holding pairs. So we should be able to write
introduce shared variables: add a new instance variable in the
class ObjClass
to hold a dictionary of shared variable bindings (a
symbol and a value) that can be queried using specific methods:
sharedVariableValue:
, sharedVariableValue:put:
.
Selected definitions
Smith was the first to introduce reflection in a programming language with 3Lisp . He defines reflection as:
- An entity's integral ability to represent, operate on, and otherwise deal with itself in the same way that it represents, operates on and deals with its primary subject matter.
In the context of meta-object protocols, Bobrow refines the definition as follows:
- Reflection is the ability of a program to manipulate as data something representing the state of the program during its own execution. There are two aspects of such manipulation: introspection and intercession (...) Both aspects require a mechanism for encoding execution state as data; providing such an encoding is called reification.
Maes proposed some definitions for reflexive programming :
- A computational system is something that reasons about and acts upon some part of the world, called the domain of the system.
- A computational system may also be causally connected to its domain. This means that the system and its domain are linked in such a way that if one of the two changes, this leads to an effect upon the other.
- A meta-system is a computational system that has as its domain another computational system, called its object-system. (...) A meta-system has a representation of its object-system in its data. Its program specifies meta-computation about the object-system and is therefore called a meta-program.
- Reflection is the process of reasoning about and/or acting upon oneself.
- A reflective system is a causally connected meta-system that has as object-system itself. The data of a reflective system contain, besides the representation of some part of the external world, also a causally connected representation of itself, called self-representation of the system. [...] When a system is reasoning or acting upon itself, we speak of reflective computation.
- A language with a reflective architecture is a language in which all systems have access to a causally connected representation of themselves.
- A programming environment has a meta-level architecture if it has an architecture which supports meta-computation, without supporting reflective computation.
- The meta-object of an object X represents the explicit information about X (e.g. about its behavior and its implementation). The object X itself groups the information about the entity of domain it represents.


Russell Purvis, V. Sambamurthy
Attempts to characterise 'traditional IS design'. Articulates designers' perspectives on working alongside users and tapping their creativity.
Scanned


Add Video
If you'd like to add videos to Find Sign’s results, that’s great! Here are some basic requirements:
- You can post your videos on Instagram, Youtube, or your own website
- You must be a fluent, experienced Auslan user, or you must be making the videos with guidance from fuent Auslan users who check you are doing it right
- If you add videos of new, made up signs, you need to consistently indicate which ones are new inventions, for example using a different #hashtag on those videos, for example: #homesign
- You must have a way people can contact you with feedback, if they feel your sign video needs more context or contains a mistake. For example you could make sure comments are enabled on Youtube or Instagram videos, or on a personal website you could include a feedback form or contact details.
If you can do everything in that list, you should contact Phoenix and we can talk about the details.


A two-track conference on the latest HTML5 developments
The web keeps evolving. There's a wealth of new technologies to keep up with! ContosoConf is an in-depth exploration of HTML5, CSS3, and JavaScript, in the heart of Seattle, WA.
Don't miss the best speakers in the business, talking about the future of the web.


JavaScript is disabled on your browser.
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev Package
Next Package
Frames
No Frames
All Classes
Package thomsonreuters.dss.api.extractions.schedules.complex
Class Summary
Class
Description
CompositeExtendedTriggerInformation
CompositeExtendedTriggerInformation.Builder
DataAvailabilityTrigger
DataAvailabilityTrigger.Builder
DataAvailabilityTriggerTimeout
DataAvailabilityTriggerTimeout.Builder
EndOfDayExtendedTriggerInformation
EndOfDayExtendedTriggerInformation.Builder
ExtendedTriggerInformation
ImmediateTrigger
ImmediateTrigger.Builder
InstrumentTriggerDetail
InstrumentTriggerDetail.Builder
MonthlyRecurrence
MonthlyRecurrence.Builder
PremiumPricingExtendedTriggerInformation
PremiumPricingExtendedTriggerInformation.Builder
ScheduleImportResult
ScheduleImportResult.Builder
ScheduleImportSettings
ScheduleImportSettings.Builder
ScheduleRecurrence
ScheduleTrigger
ScheduleTrigger.Builder
SingleRecurrence
SingleRecurrence.Builder
TechnicalIndicatorsExtendedTriggerInformation
TechnicalIndicatorsExtendedTriggerInformation.Builder
TimeTrigger
TimeTrigger.Builder
WeeklyRecurrence
WeeklyRecurrence.Builder
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev Package
Next Package
Frames
No Frames
All Classes
Copyright © 2018–2020. All rights reserved.


I'm happy to be speaking about common_schema at Percona Live London, Dec 4th, 2012. This will be the first chance for me to speak about common_schema, what I believe to be an extremely useful companion to your MySQL server.
I will show you how common_schema can leverage your SQL skills and give you new powers. Stuff you had to be SQL-Perl-super-expert to work through is easily attainable with common_schema and QueryScript. Some maintenance, security and auditing tasks are now a breeze. Writing server side scripts can be fun!
What I won't do:
- Read the fancy manual aloud
- Walk you through every possible view, column, function, parameter and script
What I will do:
- Explain the nature of common_schema, show you the concepts behind it (and it is built with concepts in mind)
- Provide with selected examples (schema analysis, security, processes & transactions) -- there's much to go by, but no boring drill down into all details.
- Expose some cool hacks with QueryScript
- Do very brief (as time allows) live demos.
common_schema is an open source project and released under the BSD license.
Last April Roland Bouman gave a great talk about common_schema. This will not be the same talk; a lot has been developed by this time.
I'll be speaking at a very challenging time slot; the three other talks running concurrent to my own are all great ones; I actually wanted to attend all three of them. Heck, Peter wants to (though contrary to belief he can't fork() himself). So, no hard feelings if you choose another talk during this time slot. But I do know where you live.
comments powered by Disqus


| < Day Day Up > |
VanLoan's book [303] is an outstanding treatment of the Fast Fourier Transform. Press, Flannery, Teukolsky, and Vetterling [248, 249] have a good description of the Fast Fourier Transform and its applications. For an excellent introduction to signal processing, a popular FFT application area, see the texts by Oppenheim and Schafer [232] and Oppenheim and Willsky [233]. The Oppenheim and Schafer book also shows how to handle cases in which n is not an integer power of 2.
Fourier analysis is not limited to 1-dimensional data. It is widely used in image processing to analyze data in 2 or more dimensions. The books by Gonzalez and Woods [127] and Pratt [246] discuss multdimensional Fourier Transform and their use in image processing, and books by Tolimieri, An, and Lu [300] and Van Loan [303] discuss the mathematics of multidimensional Fast Fourier Transforms.
Cooley and Tukey [68] are widely credited with devising the FFT in the 1960's. The FFT had in fact been discovered many times previously, but its importance was not fully realized before the advent of modern digitial computers. Although Press, Flannery, Teukolsky, and Vetterling attribute the origins of the method of Runge and König in 1924, an article by Heideman, Johnson, and Burrus [141] traces the history of the FFT as far back as C. F. Gauss in 1805.
| < Day Day Up > |


The Team
Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough. Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough. Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough. Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough. Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough. Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough. Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough.
Francesca Mangialardo
Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough.
Carlo Teo Pedretti
Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough.
Mattia Spadoni
Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough.
Description of Data
Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough.
RDF
Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough.
Linked Open Data and Semantic Web
Divide details about your product or agency work into parts. Write a few lines about each one. A paragraph describing a feature will be enough.


The characteristics of beauty are thus useful properties that yield an optimal perception of the object they apply to. […] Men can understand what is ordered, measured and delineated far better than what is chaotic, without clear boundaries, etc.
She takes the dual analysis of Poincaré, and quotes him to lay out the fact that there is a functional role to aesthetics. In order to investigate this, she turns to LA
.


{{ error.statusCode }}
{{ error.message }}
The path {{ url }} is not bugfree.
Try searching or go to Associate Degree in Computer Programming
homepage.
{{ error.message }}
The path {{ url }} is not bugfree.
Try searching or go to Associate Degree in Computer Programming
homepage.


HealthCare
COVID Tracking and Escalation
As of 30th June 2020, there are 560,000+ cases of the novel Corona Virus reported in India, out of which about 16,500 people have lost there lives, and the worse part is this number is still growing.
There are two ways to combat COVID-19, Flattening the curve, or raising the line. While flattening the curve is achieved by people being socially distant, raising the line is achieved by raising the capacity of healthcare facilities available. Our Web Application is based on the second aspect, i.e raising the line.
The Novel Coronavirus has four stages of transmission:
Stage 4: National Epidemic
India as of today has entered stage 3 and there still isn't any sign of vaccines or drugs. So the only way out currently is to stop further spread of this virus as much as we can.
We at team covidcoders, propose a Web-application which is preventive, personalized and most importantly affordable. Our web-app called, 'Covid Care', serves the purpose of tracking and escalation of people who might be COVID suspects based on the inputs provided by individuals. This information is provided by the user voluntarily and stays safe within our database. We do not store any essential data, as Security of the system is our priority. The WebApp provides minimalist interface aimed at users from all age groups.
With our product, we implement two chatbots, one of them is designated for a pre screening of the patient which is done before assigning a doctor, and the other a 'Mental Health' Chatbot, which is aimed to check the User's mood and provide them engaging and fun activities.
The second phase of the WebApp is aimed at reaching out to available doctors, booking tests and provides news information about the current state of COVID around the world. It also implements a feature of 'reporting people' using which people can report probable COVID suspects.
There's a third separate section in which we embed reliable information from sources such as YouTube, News Sources, and Quizzes as the basic informational guide.
Covid Care is expanded to a mobile application which is a WebView of our WebApplication and is built using React Native.
We also implement a 'tracking' feature for the User to track their health visually by synthesizing data in the form of vitals taken during the User's conversation with our Chatbot.
We also plan to have an in house Mental Assessment Quiz that will help the User stay happy and sane even when they are restricted to four walls.
With Covid Care, we aim at providing a simple interface so users from all age groups can use it, and can be aware about the situation. Due to restrictions in movement, and the lockdown that we are under, most people are unable to consult physicians/doctors or book tests. Our Product, Covid Care comes to aid as it connects individuals with doctors provides features as online pathology labs, which are functional in the zone so the user can avail these neccesities without having to step out of their houses. We provide simple and minimal UI/UX in a small storage space as we provide a simple WebView of our Web App in a React Native Application.
We have come up with an idea, 'STAE-C', which expands to 'Systematic Tracking and Escalation Checking' for COVID-19. The Process Flow is in the following order:
If the test results come positive, details of the user are shared with designated authorities for a better escalation.
The User's personal details as Address or Mobile Number are kept private. Only Name, Age, gender and other essential details are shared with the Doctor. Aforementioned details and the Email Address of the user are shared with the Pathology Lab to enable the User to view and connect with the Lab and vice versa. Only if the result is positive, all required details are shared with authorities.
This process reduces unwanted hastle by reducing the time and effort that needs to be put up by a user to test himself or herself for COVID. Users will be at ease to use the app irrespective of their age because of its simplicity and integration, all at one place, while boosting the efficiency in monitoring the situation and people.


Gemma Collins shows off her new hair on the ITV Palooza red carpet
Fringe benefits!
by Nancy BrownFresh from her trip to Dubai, Gemma Collins rocked a new hairstyle on the red carpet of ITV's Palooza.
Wearing a floor-length green sequinned dress from her own collection, Gemma showed off her curves – and her new bangs – at London's Royal Festival Hall.
Arriving at the party, the style chameleon appeared to have had a fringe cut in as she posed up a storm on the red carpet.
Smiling broadly, Gemma's wore her long flowing blonde locks in loose waves over her shoulders.
"You look beautiful Gemma," cooed one of the star's fans.
Read more: Holly Willoughby leads the fashion charge on the ITV Palooza red carpet
"Your hair looks amazing. I have the same shaped face but haven’t had the guts to get a fringe cut. Seeing this has given me a bit more confidence," said another.
However, we may have good news for fans of Gemma's fringe.
Read more: Bookies reveal their favourite to win this year's I'm A Celebrity
Inside, as she shared videos of Olly Murs performing with Sir Tom Jones, Gemma clearly decided that enough was enough and the fringe had to go.
She could be seen on her Instagram Stories fringe-less, leading some to speculate that she must've worn a clip-on fringe for her arrival.
As she left the glitzy party, Gemma's fringe was nowhere to be seen.
A month ago, Gemma wowed fans with another new 'do as she appeared at a London event sporting a choppy bob, having ditched her hair extensions.
Gemma recently appeared to confirm she was back with on/off beau James Argent after being seen spending time with him during her trip to Dubai.
Head to our Facebook page @EntertainmentDailyFix and let us know what you think of our story.


The output of this page can be seen in your javascript console.
#localpage2 with params
#localpage2 with params (with array)
The following route will be enabled after 20seconds
#localpage3 with params
The following link will show how a default route works
#localpage4


Our business is located in {{item.neighbourhood}}
For more info, contact us on our email below:
{{item.business_email}}


Module ROT.DijkstraMap
DijkstraMap Pathfinding.
Based on the DijkstraMap Article on RogueBasin, http://roguebasin.roguelikedevelopment.org/index.php?title=The_Incredible_Power_of_Dijkstra_Maps
Functions
| DijkstraMap:__init (goalX, goalY, mapWidth, mapHeight, passableCallback) | Constructor. |
| DijkstraMap:compute () | Establish values for all cells in map. |
| DijkstraMap:addGoal (gx, gy) | Add new goal position. |
| DijkstraMap:removeGoals ([gx=nil[, gy=nil]]) | Remove all goals. |
| DijkstraMap:writeMapToConsole (returnString) | Output map values to console. |
| DijkstraMap:getWidth () | Get Width of map. |
| DijkstraMap:getHeight () | Get Height of map. |
| DijkstraMap:getDimensions () | Get Dimensions as table. |
| DijkstraMap:getMap () | Get the map table. |
| DijkstraMap:getGoalX () | Get the x-value of the goal cell. |
| DijkstraMap:getGoalY () | Get the y-value of the goal cell. |
| DijkstraMap:getGoal () | Get the goal cell as a table. |
| DijkstraMap:dirTowardsGoal (x, y) | Get the direction of the goal from a given position |
| DijkstraMap:iterateThroughMap (callback) | Run a callback function on every cell in the map |
Functions
- DijkstraMap:__init (goalX, goalY, mapWidth, mapHeight, passableCallback)
-
Constructor.
Parameters:
- goalX int x-position of cell that map will 'roll down' to
- goalY int y-position of cell that map will 'roll down' to
- mapWidth int width of the map
- mapHeight int height of the map
- passableCallback function a function with two parameters (x, y) that returns true if a map cell is passable
- DijkstraMap:compute ()
- Establish values for all cells in map. call after ROT.DijkstraMap:new(goalX, goalY, mapWidth, mapHeight, passableCallback)
- DijkstraMap:addGoal (gx, gy)
-
Add new goal position.
Inserts a new cell to be used as a goal.
Parameters:
- gx int the new x-value of the goal cell
- gy int the new y-value of the goal cell
- DijkstraMap:removeGoals ([gx=nil[, gy=nil]])
-
Remove all goals.
Will delete all goal cells. You must insert another goal before computing.
You can specify one goal to be inserted after the goal remove takes place.
The method only checks that the coordinates are provided before setting the new goal cell.
Parameters:
- gx int Will use this value as the x-coordinate of a new goal cell to be inserted (default nil)
- gy int Will use this value as the y-coordinate of a new goal cell to be inserted (default nil)
- DijkstraMap:writeMapToConsole (returnString)
-
Output map values to console.
For debugging, will send a comma separated output of cell values to the console.
Parameters:
- returnString boolean[opt=false] Will return the output in addition to sending it to console if true.
- DijkstraMap:getWidth ()
-
Get Width of map.
Returns:
-
int
w width of map
- DijkstraMap:getHeight ()
-
Get Height of map.
Returns:
-
int
h height of map
- DijkstraMap:getDimensions ()
-
Get Dimensions as table.
Returns:
- table dimensions A table of width and height values
- int dimensions.w width of map
- int dimensions.h height of map
- DijkstraMap:getMap ()
-
Get the map table.
Returns:
-
table
map A 2d array of map values, access like map[x][y]
- DijkstraMap:getGoalX ()
-
Get the x-value of the goal cell.
Returns:
-
int
x x-value of goal cell
- DijkstraMap:getGoalY ()
-
Get the y-value of the goal cell.
Returns:
-
int
y y-value of goal cell
- DijkstraMap:getGoal ()
-
Get the goal cell as a table.
Returns:
- table goal table containing goal position
- int goal.x x-value of goal cell
- DijkstraMap:dirTowardsGoal (x, y)
-
Get the direction of the goal from a given position
Parameters:
- x int x-value of current position
- y int y-value of current position
Returns:
- int xDir X-Direction towards goal. Either -1, 0, or 1
- int yDir Y-Direction towards goal. Either -1, 0, or 1
- DijkstraMap:iterateThroughMap (callback)
-
Run a callback function on every cell in the map
Parameters:
- callback function A function with x and y parameters that will be run on every cell in the map