From: Jason Kantz
Subject: Assumptions about Packages and Bottom up programming
Date:
Message-ID: <wkbt4dtdw4.fsf@kantz.com>
I'm trying educate myself on packages. See any problems with these
assumptions?
1. Making separate packages out of only a few related functions is a
waste of time.
2. Unless it is a huge system, an application is better off keeping
all of it's functions in one package. So, for example, if I have a
simple tree protocol that I used somewhere else, I avoid unecessary
comlexity by just moving that source file into my application's
package.
3. When defining a package, include another package in a :use clause
only when the application uses many functions from that package.
Otherwise just load the package separately and use package
qualifiers ... package:function
--
Jason Kantz
http://kantz.com/jason/
From: Barry Margolin
Subject: Re: Assumptions about Packages and Bottom up programming
Date:
Message-ID: <pQyA4.110$Hp4.2619@burlma1-snr2>
In article <··············@kantz.com>, Jason Kantz <·····@kantz.com> wrote:
>I'm trying educate myself on packages. See any problems with these
>assumptions?
They seem pretty reasonable. Congratulations, few people get this
early on.
>
>1. Making separate packages out of only a few related functions is a
> waste of time.
>
>2. Unless it is a huge system, an application is better off keeping
> all of it's functions in one package. So, for example, if I have a
> simple tree protocol that I used somewhere else, I avoid unecessary
> comlexity by just moving that source file into my application's
> package.
Maybe, maybe not. If you use this tree protocol in lots of different
applications, you'll end up with lots of copies of the source file, which
would be a maintenance headache of its own.
What you might want to do is bundle up all your little utility functions
that might be used by different application packages into a single package
of its own. So distributing an application would involve distributing two
packages: the utility package and the application package.
>
>3. When defining a package, include another package in a :use clause
> only when the application uses many functions from that package.
> Otherwise just load the package separately and use package
> qualifiers ... package:function
>
>--
>Jason Kantz
>http://kantz.com/jason/
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Tim Bradshaw
Subject: Re: Assumptions about Packages and Bottom up programming
Date:
Message-ID: <ey366ul13p9.fsf@cley.com>
* Jason Kantz wrote:
> 2. Unless it is a huge system, an application is better off keeping
> all of it's functions in one package. So, for example, if I have a
> simple tree protocol that I used somewhere else, I avoid unecessary
> comlexity by just moving that source file into my application's
> package.
I think this depends. If you have a (possibly small) subsystem (or
whatever you want to call it) which you intend to reuse all over the
place then I think it's worth putting it into a package, otherwise you
end up either with lots of copies of the sources to maintain, or with
potentially lots of copies of it loaded in different packages.
What I do is kind of the flip-side of that, in that I have a whole
bunch of small utility-type things all of which arrange to live in a
HAX package, which I then can just use or refer to.
It's slightly a matter of taste though, of course: your assumptions
aren't unreasonable I think.
--tim
From: Jason Kantz
Subject: Re: Assumptions about Packages and Bottom up programming
Date:
Message-ID: <wk4sa1kacv.fsf@kantz.com>
>
> I think this depends. If you have a (possibly small) subsystem (or
> whatever you want to call it) which you intend to reuse all over the
> place then I think it's worth putting it into a package, otherwise you
> end up either with lots of copies of the sources to maintain, or with
> potentially lots of copies of it loaded in different packages.
>
> What I do is kind of the flip-side of that, in that I have a whole
> bunch of small utility-type things all of which arrange to live in a
> HAX package, which I then can just use or refer to.
>
> It's slightly a matter of taste though, of course: your assumptions
> aren't unreasonable I think.
>
> --tim
So if I am really trying programming bottom up, I isolate aspects of
my program that could be used for a variety of applications. Once I
have isolated these layers, I write them each in a package. If there
is a layer of functionality that is trivial--but separable--I can just
throw that into a misc utility package with the other generally
trivial functions and macros. Then I make a separate package for my
application that uses all the lower layers.
I've encountered recommendations that lisp apps commonly keep
everything in one package. I worked on an app that did this. It had
a 3d drawing system in the same package as the app and it ended up so
spaghettied with other layers that it became a pain to take it out and
use it for anything else.
Jason Kantz <·····@kantz.com> writes:
> So if I am really trying programming bottom up, I isolate aspects of
> my program that could be used for a variety of applications. Once I
> have isolated these layers, I write them each in a package. If there
> is a layer of functionality that is trivial--but separable--I can just
> throw that into a misc utility package with the other generally
> trivial functions and macros. Then I make a separate package for my
> application that uses all the lower layers.
That seems like a good approach to handle packages and application
development in general. It will make sure that the lower-level
functionality is kept general and clean, and the higher-level stuff
neither grows too complex, nor will become overly dependend on
specifics of the lower-level implementations.
> I've encountered recommendations that lisp apps commonly keep
> everything in one package. I worked on an app that did this. It had
I think the recommendation isn't a contradiction to the approach
outlined above. In the context of the one-app-one-package
recommendation, my concept of application will only encompass the
higher-level specific functionality, and therefore isn't in conflict
with the bottom-up multiple packages approach.
> a 3d drawing system in the same package as the app and it ended up so
> spaghettied with other layers that it became a pain to take it out and
> use it for anything else.
Yes, I think mixing distant lower-level and higher-level layers in one
package should be avoided...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Marco Antoniotti
Subject: Re: Assumptions about Packages and Bottom up programming
Date:
Message-ID: <lwaejs3d54.fsf@parades.rm.cnr.it>
Jason Kantz <·····@kantz.com> writes:
> >
> > I think this depends. If you have a (possibly small) subsystem (or
> > whatever you want to call it) which you intend to reuse all over the
> > place then I think it's worth putting it into a package, otherwise you
> > end up either with lots of copies of the sources to maintain, or with
> > potentially lots of copies of it loaded in different packages.
> >
> > What I do is kind of the flip-side of that, in that I have a whole
> > bunch of small utility-type things all of which arrange to live in a
> > HAX package, which I then can just use or refer to.
> >
> > It's slightly a matter of taste though, of course: your assumptions
> > aren't unreasonable I think.
> >
> > --tim
>
> So if I am really trying programming bottom up, I isolate aspects of
> my program that could be used for a variety of applications. Once I
> have isolated these layers, I write them each in a package. If there
> is a layer of functionality that is trivial--but separable--I can just
> throw that into a misc utility package with the other generally
> trivial functions and macros. Then I make a separate package for my
> application that uses all the lower layers.
Well. IMHO a "MISC" package is not the way to go. If you have
"little" things which are "logically" separable, then put them in a
separate package by all means.
Of course, your definition of "logically" is the key point.
> I've encountered recommendations that lisp apps commonly keep
> everything in one package. I worked on an app that did this. It had
> a 3d drawing system in the same package as the app and it ended up so
> spaghettied with other layers that it became a pain to take it out and
> use it for anything else.
Exactly. E.g., I believe that CLIM-SYS and CLIM-USER are a good
example of how *not* to do things. (You could argue that COMMON-LISP
is also an example of how *not* to do things :) but we have to live
with that)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Tim Bradshaw
Subject: Re: Assumptions about Packages and Bottom up programming
Date:
Message-ID: <ey3n1nsy7p2.fsf@cley.com>
* Marco Antoniotti wrote:
> Exactly. E.g., I believe that CLIM-SYS and CLIM-USER are a good
> example of how *not* to do things. (You could argue that COMMON-LISP
> is also an example of how *not* to do things :) but we have to live
> with that)
I think you probably mean CLIM not CLIM-USER. There are no more
symbols in CLIM-USER than there are in CL-USER.
In any case, I disagree with this. If I want to use CLIM, then *I
want to use CLIM dammit*, and I want to be able to say (use-package
:clim), not some vast incantation involving 98 different packages (in
fact, I *already* have to say more than this unfortunately).
And of course CLIM implementations *are* in lots of packages, CLIM
just exports all the interesting stuff, just like CL does.
It seems to me that your complaint is rather that you'd like to have
all these little packages documented for CLIM and CL. That's a more
reasonable argument (but still wrong I think).
--tim
In addition to the excellent advice posted by others, I would like to
add:
In addition to program packages, it is sometimes advantageous to
define _data_ packages.
These packages is then essentially used as hash tables indexed on
symbols but with the added advantage that you can easily refer to
values in it in a very readable way: DATA-PACK:NAME
Stig Hemmer,
Jack of a Few Trades.