19.2 Creating Objects

The function make-instance provides a convenient way to create objects of any flavor. The flavor of the object to be created and the initializations to be done are given as parameters in a way that is fully independent of the internal representation of the object.

19.2.1 Methods

The function ”=>”, whose name is intended to suggest the sending of a message to an object, is usually used to invoke a method.

Examples:

The first argument to => is the object being operated on: my-object and thing1 in the examples. The second argument is the name of the method to be invoked: zap and set-location. The method name is not evaluated. Any further arguments become arguments to the method, and are evaluated. (There is a function send which is just like => except that the method name argument is evaluated just like everything else.)

Once an object is created, all operations on it are performed by methods defined for its flavor. The flavor definition also defines some methods. For each ”gettable” instance variable, a method of the same name is defined which returns the value of that instance variable. For ”settable” instance variables a method named ”set-<variable name>” is defined. Given a new value, this method sets the instance variable to have that value.

19.2.2 Protection of Objects

Most LISP’s, and PSL in particular, leave open the possibility for the user to perform illicit operations on LISP objects. Instances of a flavor are represented as ordinary LISP objects (evectors at present), so in a sense it is quite easy to do illicit operations on them: just operate directly on its representation (do evector operations).

On the other hand, there are major practical pitfalls in doing this. The representation of a flavor of objects is generated automatically, and there is no guarantee that a particular flavor definition will result in a particular representation of the objects. There is also no guarantee that the representation of a flavor will remain the same over time. It is likely that at some point evectors will no longer even be used as the representation.

In addition, using the objects package is quite convenient, so the temptation to operate on the underlying representation is reduced. For debugging, one can even define a couple of extra methods ”on the fly” if need be.