[closer-devel] Adding dynamic-wind to ContextL

[Attila Lendvai]

>> I can relate to that. I'd be fine if the dynamic-wind stuff came in its
>> own defsystem, but is distributed with ContextL. It's like the "use the
>> most specific function" rule of thumb.
>
> Is that common practice in other CL libraries?
>
> Do I understand the idea right? I set up the same package
> and export the same symbols as before, but only implement
> a subset of them, by loading only a subset of the implementation
> files, and I do this by defining a system that only specifies that
> subset of the implementation files. Is that correct?


people (well, we) usually create a new separate system definition and
a separate package for a standalone functionality. if the
functionality is tightly coupled then it's a good idea to keep them in
one repo, but we usually just set up also a new repo for the
standalone part. and a new project was just born.

we do the same-repo/different-system practice for things like
hu.dwim.util, which contains various other systems which are not
really useful libraries in themselves, but at the same time we don't
want to force their dependencies on all our libs that use parts of
hu.dwim.util.

hu.dwim.wui is our web server, and it has several asdf systems that
bring in more and more machinery that build on each other. then users
can chose how much of it they need. we use a shared hu.dwim.wui
package for them, but we keep the exports at the definition sites (as
opposed to a central package.lisp), so that's not a big issue.

but back to dynamic wind: the cost for running a separate project
seems big, but if you look at it from the point of view that it's just
a new darcs repo next to contextl, then it doesn't seem so bad. so,
i'd set up a new repo, a new package, move the code there, and then we
have one more CL lib... :)

just some 0.02,

-- 
 attila