🚀 go-pugleaf

Bryan,

 You might try this:

(defclass complex ()
 ((real-part :accessor real-part)
  (imag-part :accessor imag-part)))

(defclass real (complex)
 ((imag-part :allocation :class
	     :initform 0)))

 I haven't tested it, but I imagine (pun intended) that the class
allocation on the subclass slot will override the instance allocation
on the parent class.  The IMAG-PART accessor should still return 0,
but instances of REAL won't allocate space for a slot value.  Instead,
the first time you create an instance of REAL, the class slot will be
initialized to 0.

 Your mileage may vary depending on the implementation. 

 But do notice that I didn't have to use the MOP.


 Of course, you have already noted that one would never handle complex
numbers this way in CL.  CL already has convenient facilities for
complex numbers.

 But suppose you really did want to model complex numbers with CLOS (I
remember a paper at OOPSLA-86 that modelled such algebraic constructs
in SmallTalk).  Wouldn't it make more sense to work constructively,
rather than subtractively?  For example:

;;; REAL is a built-in type.
(defmethod imag-part ((r real))
   0)

(defmethod real-part ((r real))
   r)

(defclass complex ()
 ((real-part :accessor real-part)
  (imag-part :accessor imag-part)))

 Once again, notice that I didn't have to use the MOP.


 Be sure you don't fall into the trap of thinking generic functions
must be anchored in classes.  CLOS goes beyond that -- generic
functions are independent of any particular class, and methods can
specialize on any class or type.

 Sometimes it takes effort to avoid confusing the class hierarchy with
an is-a hierarchy.  Although class inheritance can often be a good
medium to model is-a relationships (because CL's convenient type-of
mechanism), you may not always want to do this.  There are other ways
to use class structure inheritance.


 -Rick

*-------------------------------*
| Copyright 1992, Rick Dinitz	|
| dinitz@tss.com		|
*-------------------------------*


>I have an application where it is redundant to store a value for an
>instance variable in a specialization of a class. I'll use numbers as
>as an analogy (not that one would do this with numbers in common lisp):
>
>One might have a class called complex-number that has two instance
>variables real-part and imaginary part. A second class real-number
>would be a specialization of complex-number but doesn't need to store
>a 0 in the imaginary part. One could simply write an accessor that
>always returns 0.
>
>Has anyone used the MOP to allow a class such as real-number to not
>have to store the unwanted instance variables? I'd love to have
>someone send me an example so that I can avoid doing the work myself.