jonl%kuwait@lucid.com (Jon L White) (06/28/91)
Somehow, the msg below didn't make it through the mailer; hence
I'm trying again to send it (apologies if you already received it).
Incidentally, the main content of this messages is about the "Fear of
packages" rather than CLOS methods; but I'll continue it under the
above subject line until someone objects. Privately, someone has
pointed out that some "Fear" can be healthy, when it is based on
knowledge; in that case, perhaps I should have called the syndrome
"The Fear and Loathing of Packages".
-- JonL --
Date: Wed, 26 Jun 91 14:50:13 PDT
From: Jon L White <jonl@kuwait>
Message-Id: <9106262150.AA12737@kuwait>
To: konstan@elmer-fudd.berkeley.edu
Cc: commonloops@cis.ohio-state.edu
In-Reply-To: Joe Konstan's message of 26 Jun 91 05:51:53 GMT <42474@ucbvax.BERKELEY.EDU>
Subject: CLOS Private Methods
re: I think that the lack of encapsulation problem is more than merely a
fear of packages.
Uh, the point of my message on this topic was twofold:
(1) The encapsulation problem, in the Common Lisp world, is more
than merely class ownership, and more than just packages.
(2) The failure to use packages in the intended way usually stems
from the "fear of packages".
One does not overcome the "fear of packages" by using them in a
non-intended way, such as trying to mimic in all gory detail the class
encapsulation of some other object-oriented languages.
re: (defmethod CLEAN ((self HOUSE))
(wash-windows self)
(scrub-floors self))
(defmethod CLEAN ((self BOAT))
(scrape-barnacles self)) ;; I show my ignorance about boats
The default behavior I want for HOUSEBOAT is to do both.
[Therefore I have to add call-next-method's in a non-encapsulated
way, or do some other unworkable kludge; and thus CLOS has a
predispostion against encapsulation]
Ever hear of PROGN method combination?
re: [packages] I found this to be a difficult enough problem so as to make
it not worth pursuing far. When interpreted, I could load one set of
code or the other, use that package, and then load the code that called
the video successfully. But, there was no way to compile the code that
called the video or even load it in advance since to compile or load that
code it needed to resolve the package of the symbols and would create
them locally if they weren't already imported.
Your tale of woe has been repeated many times (if you're interested in
hearing the "misery loves company" story.)
One of the components of the "fear of packages" is hoping that the usual
order-independence for loading lisp files applies to package details
also. It does not. I know, it's very deceptive in that it almost works.
But the *order-dependence* is precisely why DEFPACKAGE was defined; it
provides no new functionality, but serves to emphasize the need to define
some things -- packages in this particular case -- *before* using them.
So a file of defpackage definitions should be, in a DEFSYSTEM sense,
required before either compiling or loading the main application file.
Sort of like a .h requirement for C code.
The major gap is really not the order dependency however (that is, once
you are aware of it); the hard gap is in the incremental, probably-
inconsistent changes to packages that inevitably occur during serious
program develpoment. As lgm pointed out, it is no easy task to find
all the files/modules that need to be recompiled because of a particular
package change. It is for this reason -- the murky gray area of module
dependence on particular packgage components -- that the accepted
definition of DEFPACKAGE doesn't particularly provide for a semantics
of re-definition.
-- JonL --