Frank Goenninger wrote:
Hi Kenny, hi all:
While developing a library here . I see that I need some observers being defined to handle operations of the I/O device. Naturally I am coding these as part of the library which I plan to ship just as a compiled file.
The main application also needs to define observers on some Cell slots to update the GUI and other stuff. As an observer for the slot is already defined I am denied to define another one.
Yes and no.
(defgeneric slot-value-observe (slotname self new old old-boundp) #-(or cormanlisp clisp) ;; Hey, I think clisp does PROGN now! (:method-combination progn))
So we have a PROGN method combo which means subclasses and superclasses can both define the same observer and both will run. If you do not think your users will be subclassing, say, XXX, we still have a problem. Maybe then make your library class XXX-INTERNAL (unexported), subclass with XXX (exported/documented). Or you can require users to subclass, and enforce that in initialize-instance.
Another trick is that possibly an :around method will work. PROGN does not let you also do :before/:after, but you an do :around. Not sure how that helps in this situation, because you might also want to let users at the :around method.
A final trick would be to have your XXX/SLOT-A observer call USER-SLOT-A-OBSERVER (standard method combo) before/after doing what you want to do yourself in the observer.
I guess this is a common problem in delivering CLOS applications. I wager most folks use the XXX-INTERNAL trick, or require users to subclass. If you think most users will be subclassing anyway, make it a requirement. That way it does not actually bother many people.
Side note: you do not need an extra XXX-INTERNAL if your implementation itself naturally provides unpublished superclasses. I used tk-object and widget and item for that in Celtk, because those are all abstract classes if you will.
kt