Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!dog.ee.lbl.gov!ucsd!usc!snorkelwacker!apple!sun-barr!olivea!samsung!uunet!cme!cam!ARTEMIS From: miller@cam.nist.gov (Bruce R. Miller) Newsgroups: comp.lang.lisp Subject: Re: Common Lisp Package System Considered Harmful Message-ID: <2865200060@ARTEMIS.cam.nist.gov> Date: 18 Oct 90 00:54:20 GMT References: <271CDC30.1E54@wilbur.coyote.trw.com> Sender: news@cam.nist.gov Followup-To: comp.lang.lisp Organization: NIST - Center for Computing and Applied Mathematics Lines: 64 In article <271CDC30.1E54@wilbur.coyote.trw.com>, Scott Simpson writes: > In article <2298@heavens-gate.lucid.com> pab@lucid.com (Peter Benson) writes: > >In article <271BA6D1.5B83@wilbur.coyote.trw.com> scott@wiley.uucp (Scott Simpson) writes: > > My first suggestion was to make a separate package for each > > class. My reasons for this were simple: I wished to hide everything... > > > >This seems like overkill. ... > > Since I haven't quite figured out how packages can be used with CLOS > classes usefully I can't make a judgement on their power and whether > what I am doing is overkill or not. I am not convinced that packages > even deserved to be given the connotation "powerful". ... (with-disclaimers-and-IMHO () I think that CLOS & Packages are two mechanisms with different scales and intents. And although they both seem to deal with `information hiding' they deal with it in quite different ways. One point is that, in Lisp, nothing is REALLY hidden -- some things are just a little less visible than others. Want a non-exported symbol from a package? Use two colons. Want to get at an unapproved slot from a clos instance? Just use slot-value. On the one hand, I think that packages are (very) useful at a coarse grain: for example at the application level. I've never written an application with more than 2 packages and even those were cases where the one might be used as a separate set of tools. [I do often write `user-level' programs for using an application and define a package for each `user program' which uses the application's package. It eases using the application's tools and avoids clashes between different, similar programs] They really come in useful when you have a well `lived in' lisp environment where there are multiple applications loaded and ready to run (or are running, if you have multi-tasking lisp environment). Of course, you determine which symbols should be used by outsiders by exporting them. If an outsider has to use two colons, he implicitly acknowledges the risk. Anyway, that's how I use packages, but maybe I'm an unsophisticated package user. On the other hand, it is my impression that with CLOS (I haven't done much CLOS yet, but I have done a lot with Flavors --- I think it's the same as far as this discussion is concerned) one differentiates between the `external' and `internal' interface to a class of objects simply by saying so! That is, the developer announces that these are the routines to use. Any other routines are for internal use only. Packages help in so far as it helps (loosely) enforce that distinction to users outside of the application, but doesn't help between modules within the same package. You just dont call the internals by virtue of your strength of will and extraordinary discipline! As you've seen, using too many packages within the same program gets hairy. But, I dont think that CLOS really attempts to enforce any kind of barrier, and packages seems to be at the wrong level for what you want --- lisp itself isn't really into firewalls in any case. A trick I've used with some satisfaction -- as a reminder, NOT a firewall -- is to document, literally, the `documented interface' by giving a documentation string (where appropriate). If I'm in doubt about invoking a function in a particular piece of code, If m-sh-D gives me documentation, I figure it's OK, otherwise probably not. --- OK, it's far from perfect, just an idea. bruce