Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rutgers!aramis.rutgers.edu!bearcat.rutgers.edu!lou From: lou@bearcat.rutgers.edu (Lou Steinberg) Newsgroups: comp.lang.lisp Subject: Re: CLOS: is it OOP? Message-ID: Date: 19 Sep 89 17:04:13 GMT References: <19582@mimsy.UUCP> <29564@news.Think.COM> <11815@polya.Stanford.EDU> Distribution: usa Organization: Rutgers Univ., New Brunswick, N.J. Lines: 42 To: pallas@Neon.Stanford.EDU In article <11815@polya.Stanford.EDU> pallas@Neon.Stanford.EDU (Joe Pallas) writes: > [...] But I would argue that it is precisely because of > generic functions that CLOS CANNOT have protection. To have > protection, you must have a clearly defined protection boundary. > Method invocations establish such a boundary, but generic functions do > not. Not quite. In standard OOP, the traditional protection boundary is around methods belonging to a given class. (OOP languages differ as to whether that means just "class C" or "C and its descendants".) With CLOS, multi-methods can "belong" to a set of unrelated classes - one for each argument - so indeed the traditional protection boundary cannot be used when you have such methods. That does not mean that "CLOS CANNOT have protection". You just have to define other boundaries. E.g. you could give a list of classes, and say that a method is within this protection boundary if all the classes it specializes on are in this list. If you want to, you can just put one class in each list, and get the effect of the tradtional OOP boundaries. But suppose there is a case where to do some operation on two objects you want to be able to access some aspect of the internals of each object. In traditional OOP languages, this operation is a method of one of the objects, so the interface of the other object has to export enough access to allow a method of the first object to do the access the operation needs. However, once exported this access is available to the world. In CLOS with my hypothetical protection mechanism, you need only create a boundary with the two classes and put the method for this operation in that boundary. In such a case, a strict association of a protection boundary with a class would force you to subvert the protection mechanism, and leaves you with less protection than you would have had if protection boundaries were more flexible. (Note that the issue here is not one of send vs function-call syntax, but one of multi-methods versus methods specialized on only one argument.) -- Lou Steinberg uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou arpa: lou@aramis.rutgers.edu