[clean-list] Refactoring Clean Applications

Erik Zuurbier EZuurbier@Abz.nl
Thu, 3 May 2001 14:45:25 +0200


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0D3CE.ED188628
Content-Type: text/plain

Dear Cleaners,

I have developed quite a number of toy applications in Clean, and I loved
doing it. Gradually, the applications get connected: I reuse parts I have
developed earlier. As the applications grow and start to consist of many
modules, I lose oversight though, to the point that major changes become
close to impossible.

Of course I should have documented more than I have. For instance, I could
have written down for each project why I included a certain file path in the
project file. Then when the application breaks, I could redirect the
compiler to the new location of a module. Or indeed it would allow me to
decide if a certain path has become obsolete. And this is only one example
of where good documentation could help.

But somehow, I believe that a future IDE could have features that
* help me to keep an overview of my modules, projects, call graphs of
projects
* warn me when I try to make any change that damages other projects
* list which import statements and file paths have become obsolete

Have you run into the same problems? Do you have any ideas about how to
solve them?

Regards Erik Zuurbier


------_=_NextPart_001_01C0D3CE.ED188628
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">



Refactoring Clean Applications



Dear Cleaners,

I have developed quite a number of toy = applications in Clean, and I loved doing it. Gradually, the = applications get connected: I reuse parts I have developed earlier. As = the applications grow and start to consist of many modules, I lose = oversight though, to the point that major changes become close to = impossible.

Of course I should have documented = more than I have. For instance, I could have written down for each = project why I included a certain file path in the project file. Then = when the application breaks, I could redirect the compiler to the new = location of a module. Or indeed it would allow me to decide if a = certain path has become obsolete. And this is only one example of where = good documentation could help.

But somehow, I believe that a future = IDE could have features that
* help me to keep an overview of my = modules, projects, call graphs of projects
* warn me when I try to make any = change that damages other projects
* list which import statements and = file paths have become obsolete

Have you run into the same problems? = Do you have any ideas about how to solve them?

Regards Erik Zuurbier

------_=_NextPart_001_01C0D3CE.ED188628--