Time has come to consider a refactoring of our application in order to
improve organisation and coherence of it. However, we are a bit unsure
on how to approach the issue so I am calling for hints from the
learned members of the community, in the assumption that other must
have faced the same problem.
What we would like to achieve is a clearer picture of what depends on
what and the interfaces between the various parts of the code.
In some sense we need to develop a library strategy. We would like a
way to setup and/or describe a block of software such that it becomes
easier to understand (or even to check) that other blocks uses the
functionality correctly.
As my colleague puts it, if it had been a C++ application, he would
have known exactly how to attack the problem, but we feel a bit more
in the dark with our lisp application.
Just to be more explicit, let me relate the experience that lead us to
the conclusion that a refactoring is needed.
We are in process of conducting an experience where we want to take a
part of the application and put to a new use. Concretely, this means
that we are taking a bunch of files of the compilation
process.
Suppose our application consists of the files A, B, C and D, compiled
in that order.
We throw out B because it does not contain anything usefull to us and
suddenly we get a warning during the compilation of C saying something
to the effect of "variable `xyz' is assumed special". A little
investigation showed that `xyz' is defined in D but used in both B and C.
Sometime in a distant past we have added to B a "(declaim (special xyz))".
This handled the warnings that otherwise have been generated from the
compilation of both B and C but since B is now missing, we get
warnings when compiling C.
Our problem is not so much the warning itself but rather the fact that
there are such things scattered around at random places in the
code. We would like to come up with a strategy that helps collect such
things in good places.
One idea would be to have a strategy that all exported symbols must be
accompanied by an appropriate declaration and stick this into the
package file, but is that really how an experienced lisp programmer
would do it? (or is it the C programmer talking :-)
If anybody elese has any experiences, thoughts or ideas on how to
modularize larger lisp applications, I would be glad to hear about it.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech wrote:
> Time has come to consider a refactoring of our application in order to
> improve organisation and coherence of it. However, we are a bit unsure
> on how to approach the issue so I am calling for hints from the
> learned members of the community, in the assumption that other must
> have faced the same problem.
Our rather large CliniSys application went thru the same process rather
late in the game, mostly because I had brought a ton of code to the
project and the we wanted a way to say this is Kenny's and that is
CliniSys's. I thought Lisp packages would offer a nice way to do that,
and it might prove useful down the road just because it is usually good
to organize huge wadges of code into more manageable chunks, perhaps so
diff programmers might be assigned to concentrate on one
package/funtional-area or another. doc also could follow the contours of
packages. yada yada yada.
it was tedious but easy. i basically just chopped things up along the
obvious lines and then compiled over and over. compilation warnings led
me either to expand the list of exported symbols or refactor where I
thought code in one package really should not be seeing or using
something in a used package.
refactoring did not happen a lot because I try to be a good boy anyway,
but it happened enough (and in interesting enough ways) that I decided
the code-ownership exercise, however tedious, was a Good Thing in its
own right.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
On Wed, 18 Jun 2003 15:39:39 +0200, Christian Lynbech
<·················@ted.ericsson.se> wrote:
> Time has come to consider a refactoring of our application in order to
If there are no confidentiality or similar issues with the application, it
would be great if you could add an entry for it to ALU CLiki's industrial
applications page:
http://alu.cliki.net/Industry%20Application
Paolo
--
Paolo Amoroso <·······@mclink.it>
On Wed, 18 Jun 2003 15:39:39 +0200, Christian Lynbech
<·················@ted.ericsson.se> wrote:
>
>Suppose our application consists of the files A, B, C and D, compiled
>in that order.
>
>We throw out B because it does not contain anything usefull to us and
>suddenly we get a warning during the compilation of C saying something
>to the effect of "variable `xyz' is assumed special". A little
>investigation showed that `xyz' is defined in D but used in both B and C.
>Sometime in a distant past we have added to B a "(declaim (special xyz))".
>This handled the warnings that otherwise have been generated from the
>compilation of both B and C but since B is now missing, we get
>warnings when compiling C.
>
>Our problem is not so much the warning itself but rather the fact that
>there are such things scattered around at random places in the
>code. We would like to come up with a strategy that helps collect such
>things in good places.
>
>If anybody elese has any experiences, thoughts or ideas on how to
>modularize larger lisp applications, I would be glad to hear about it.
>
Split file D into two parts, D-defs and D-implementation. Since B and
C reference xyz in D-defs those files should come after D-defs in the
compiliation/load order.