what is a common practice for usage of packages -- that is, how many
packages to use in application?
there are two corner cases --
1) use just one package for all applications
2) use separate package for each module (for example, file)
in C++ the later approach -- use as many namespaces as you want -- is
frequently used, for example, in boost libraries. but in CL each package
requires some attention (manually figure out use and exports), so i'm afraid
that would be waste of time..
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> what is a common practice for usage of packages -- that is, how many
> packages to use in application?
> there are two corner cases --
> 1) use just one package for all applications
> 2) use separate package for each module (for example, file)
>
> in C++ the later approach -- use as many namespaces as you want -- is
> frequently used, for example, in boost libraries. but in CL each package
> requires some attention (manually figure out use and exports), so i'm afraid
> that would be waste of time..
Well, you could just write package::symbol everywhere.
But indeed, spliting the namespace in too many packages is boring.
At first I'd have one package per application module, but it's too
much work.
Nowadays, I have one package per application. Or possibly some more,
if it's a bigger application with reusable modules (but they they're
more considered as external libraries than application modules
properly).
--
__Pascal Bourguignon__ http://www.informatimago.com/
CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.
Pascal Bourguignon <···@informatimago.com> writes:
> Well, you could just write package::symbol everywhere.
> But indeed, spliting the namespace in too many packages is boring.
>
> At first I'd have one package per application module, but it's too
> much work.
>
> Nowadays, I have one package per application. Or possibly some more,
> if it's a bigger application with reusable modules (but they they're
> more considered as external libraries than application modules
> properly).
This is what I end up doing, too.
Alex Mizrahi wrote:
> what is a common practice for usage of packages -- that is, how many
> packages to use in application?
> there are two corner cases --
> 1) use just one package for all applications
> 2) use separate package for each module (for example, file)
>
> in C++ the later approach -- use as many namespaces as you want -- is
> frequently used, for example, in boost libraries. but in CL each package
> requires some attention (manually figure out use and exports), so i'm afraid
> that would be waste of time..
Yes, it would be a waste of time. Packages mainly exist to organize
programs in such a way that code written by different parties doesn't
step on each others toes. This is the case when you use different
applications at the same time and when you use third-party libraries
and/or want to make your own libraries available to others. Inside your
own code, packages don't buy you a lot.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 2006-11-22 19:45:16 +0000, Pascal Costanza <··@p-cos.net> said:
> Inside your own code, packages don't buy you a lot.
Well, they provide a very useful way of describing what the names in
APIs are and enforcing the use of the API (or at least making it hard
and obvious when you're violating some kinds of modularity boundaries).
Tim Bradshaw wrote:
> On 2006-11-22 19:45:16 +0000, Pascal Costanza <··@p-cos.net> said:
>
>> Inside your own code, packages don't buy you a lot.
>
>
> Well, they provide a very useful way of describing what the names in
> APIs are and enforcing the use of the API (or at least making it hard
> and obvious when you're violating some kinds of modularity boundaries).
>
>
Absolutely. At a certain point early in the life of a huge application
(but after a /lot/ of code had been written) I decided for the hell of
it to sort it all into packages (never before having been a package
person). Quite an education on the places where my design could have
been cleaner, things better abstracted, etc etc. Now I am a packager,
though I confess that in my current project I wearied of package-fussing
(I think because I may have gone a bridge too far in carving out
subsystems) and am pretty much working in one package.
The original question "how many" and the responses, oh, maybe one per
app or one per source file are disappointing. The answer to the first
question obviously is 42, don't know how you all missed it. As for the
responses that were offered, please, packages align with subsystems, the
answer is "how many subsystems do you have"?
hth, kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> wrote:
+---------------
| As for the responses that were offered, please, packages align
| with subsystems, the answer is "how many subsystems do you have"?
+---------------
And ever since Mike Padlipsky's "Elements of Networking Style"[1],
everyone has known that the answer to *that* is "How many strong
personalities do you have on your project's development team?" ;-}
-Rob
[1] "The Elements of Networking Style"
by Michael A. Padlipsky.
Prentice-Hall, 1985 [ISBN 0132681110]
Reprinted 2000 by iUniverse [ISBN 0595088791]
236pp
Appendix 3, named "Self-Framed Slogans Suitable
For Mounting", contains this one:
If you know what you're doing,
Three layers is enough.
If you don't,
Even seventeen levels won't help.
and this:
The 3/17 one
Also applies, of course,
To management hierarchies.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
(message (Hello 'Ken)
(you :wrote :on '(Thu, 23 Nov 2006 05:38:21 -0500))
(
KT> question obviously is 42, don't know how you all missed it. As for the
KT> responses that were offered, please, packages align with subsystems,
KT> the answer is "how many subsystems do you have"?
subsystems are organized as tree, but not as a flat list.
so i can merge two related subsystems into bigger one, or split one into
two.
so it's kinda same question.
as i've mentioned, boost guys can have 10 namespaces per file, they define
subsystems at high granularity :)
but i feel that usage of many namespaces is more typical for
statically-typed compiled languages. but lisp is dynamically-typed, so code
can be written fast, and there's no reasons to introduce many separate
packages -- it will slow-down code writting. if i'll need better
organization, i'll better switch to language with static types (Haskell and
ML appear good, but their syntax is too weird).
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
> as i've mentioned, boost guys can have 10 namespaces per file, they define
> subsystems at high granularity :)
...and the C++ standard library is at the other extreme with just one
namespace for everything as they used namespaces to separate language
supplied libraries from user code. But extreme cases don't always make
the best examples.
I think good package organization should naturally fall out of good
design. I find that adding packages helps me as it allows my brain to
focus on one thing at a time like any form of modularity should.
Phil
On 2006-11-23 13:55:03 +0000, ···············@gmail.com said:
> ...and the C++ standard library is at the other extreme with just one
> namespace for everything as they used namespaces to separate language
> supplied libraries from user code. But extreme cases don't always make
> the best examples.
Very similar to CL, where everything is in (or is exported from) the CL
package.
Alex Mizrahi wrote:
> what is a common practice for usage of packages -- that is, how many
> packages to use in application?
> there are two corner cases --
> 1) use just one package for all applications
> 2) use separate package for each module (for example, file)
>
> in C++ the later approach -- use as many namespaces as you want -- is
> frequently used, for example, in boost libraries. but in CL each package
> requires some attention (manually figure out use and exports), so i'm afraid
> that would be waste of time..
For C++, namespace issues are complicated by their interaction with
argument dependent lookup (ADL); i.e. IIRC, this is frequently the
reason for Boost libraries having a "detail" namespace nested within the
subsystem namespace. This is the core issue behind the advice from the
book _C++ Coding Standards_ <http://tinyurl.com/ybz6y3> to "keep a type
and its nonmember function interface in the same namespace"
<http://tinyurl.com/yela3n> and its corollary, to "keep types and
functions in separate namespaces unless they're specifically intended to
work together" <http://tinyurl.com/yzzptd>. As Common Lisp does not
support infix operator (or "normal" function) overloading, there is no
need for something like ADL. In addition, since CL is already a lisp-n
(assert (>= n 2)), and so it already puts functions into their own
namespace.
I personally don't think that CL requires more "manual" fiddling of
names (symbols) than one does with C++. In fact, I think that CL
requires less fiddling. It seems to me that in Common Lisp one
"manually" figures out which symbols to use and export while in C++ one
"manually" figures out what names are public/protected/private (similar
to whether or not a name is exported in CL) and which names should be
put into some kind of a "detail" namspace (again, this seems somewhat
analogous to the decision of whether or not a name is exported in CL).
But there is more to it than that for C++, especially when on stops to
think about all of the ways that function overloading, built-in vs
user-defined conversions, public/protected/private inheritance,
public/protected/private members, ADL, template argument deduction,
whether or not a name is dependent on a template parameter, especially
for base classes with a dependent template parameter (e.g.,
template<typename T> struct D : public Base<T> { };), whether or not C++
macros are stomping all over any kind of scoping rules for names, and
probably a few things I'm forgetting at the moment, can interact with
how one gets from a name to that which it is naming. It seems to me
that CL requires far less fiddling with names than one does in C++.