🚀 go-pugleaf

>>>>> gregor@parc.xerox.com (Gregor Kiczales) writes:

	-> In article <9208111754.AA06971@jupiter.risc.rockwell.com> kal@jupiter.risc.rockwell.com (Kevin Lovette) writes:

	->    From: kal@jupiter.risc.rockwell.com (Kevin Lovette)
	->    Date: 11 Aug 92 17:54:14 GMT

	->    I have some code that uses (setf slot-value-using-class) to trigger the update
	->    of windows on my display.  When I ported this code from Franz to Lucid it
	->    stopped working.  It turns out that accessors in Franz are implemented with
	->    slot-value, but in lucid accessors seem to directly access the slot without
	->    calling slot-value. 

	->    Is there a finalized CLOS MOP specification yet? If so, what does it specify? 

....

	-> As it turns out, the specification never comes right out and says that
	-> automatically generated accessor methods must call SLOT-VALUE-USING-CLASS
	-> and (SETF SLOT-VALUE-USING-CLASS).  But that is certainly what was
	-> intended.  Otherwise, code like your's becomes difficult (perhaps even
	-> impossible) to write.

The user can override the automatically-generated accessor methods, or
supply :around, :before or :after qualifiers to the accessor methods to carry
out the desired side-effect, without going through SLOT-VALUE-USING-CLASS.
This would solve Mr. Lovette's problem, but then somebody could call 
slot-value-using-class instead of the accessor method.
The real issue is that if there are two paths to change a slot value
you have to modify both.  

	-> The current version of PCL, unless something has changed I don't know
	-> about, supports this.  It is pretty easy to do without undue performance
	-> penalty.

In tests I did about a year ago on Lucid CLOS, reader methods on objects of
metaclass standard-class ran about 3x faster than slot-value.  There was
probably a good reason why Lucid bypassed slot-value-using-class in
implementing these -- perhaps JonL can weigh in with it.  My suspicion is that
since the method is specific to a single slot, various runtime decisions can
be moved to compile time -- the check for class-allocated slot under some
circumstances.  I can even imagine an architecture where the index into an
instance vector could be compiled in, and if a subclass inheriting the
method changed the allocation or index of the slot, new accessor methods
for that subclass could be automatically generated and compiled to
override the one from the superclass, without violating any protocol,
as long as we could tell that the superclass's accessor was automatically
generated and its functionality was thus circumscribed.