Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!ucla-cs!uci-ics!zardoz!tgate!ka3ovk!drilex!axiom!linus!john From: john@linus.UUCP (John D. Burger) Newsgroups: comp.lang.lisp Subject: Re: CLOS: is it OOP? Message-ID: <71186@linus.UUCP> Date: 14 Sep 89 23:21:36 GMT Reply-To: john@mitre.org Organization: The MITRE Corporation, Bedford MA Lines: 36 Wayne Folta writes: > ... I have been reading a book which implies that CLOS can be argued > to not be OO: > >"Because CLOS makes no effort at protection or encapsulation, some might >find that it lacks the most essential thing for an object-oriented system." > >"Generic functions are a step away from the concept of active data and back >toward the conventional division between passive data and active process." I suppose the author was referring to things like internal functions and methods. For example, one might define the SPECIAL-MULTIPLY function to be internal to the COMPLEX-NUMBER class. This guarantees that SPECIAL-MULTIPLY may only be called within methods attached to COMPLEX-NUMBER. A problem with this, in particular, is that CLOS allows multiple arguments of methods to be specialized. Thus, it's not clear that it makes sense to think of methods as "attached" to classes. I suppose the metaphor could be extended for multi-methods, but I'm not sure if it's worth it. In any case, it's straight-forward to specialize method classes and meta-classes in CLOS so as to have internal functions and methods. In particular, I imagine it could be done by specializing the way applicable methods are computed. As for other instances of protection and encapsulation, I think they could be implemented as well. That's the great thing about CLOS: since CLOS is itself a CLOS program, you can beat the hell out of it to get just about any sort of meta-level behavior. -- John Burger john@mitre.org "You ever think about .signature files? I mean, do we really need them?" - alt.andy.rooney