Thoughts about CEAN/refactoring

Joe Armstrong (AL/EAB) joe.armstrong@REDACTED
Thu Jul 6 11:36:39 CEST 2006

 Some thoughts on CEAN

How can we make CEAN? (Comprehensive Erlang Archive Network)

I want to address the following problem?

How can be keep multiple versions of code in the same 
namespace in a consistent manner?

Here's a proposal.

Rule 1

Versions are named like this AppName-Vsn

Vsn is of no significance it is just a "distinguished string"

<< It might be like this:



Rule 2

We have One source code tree:


Same as the OTP tree - with two additions

     1) A file called Dependencies
     2) A new directory called xsrc
        (short for transformed source)

Rule 3

All applications are named with the "usual" module naming convention.

ie. The application foo-Vsn has a "main module"  foo.erl
and a number of sub-modules foo_xxxxxx.erl.

External applications MUST only call exported routines from foo.erl and
NOT foo_xxxxx.erl

Rule 4

xsrc is derived from src using the information in the file

Let's assume that the file 

Contains the following:

     bar-7.0 boo-gold

This means that foo-2.3.4 depends upon bar-7.0 and boo-gold.

Now we transform the code as follows:

    all module names

      foo foo_XXXX are transformed to foo_2.3.4 foo_XXXX_2.3.4

      bar bar_XXXX are transformed to bar_7.0 and bar_XXXX_7.0

      boo boo_XXXX are transformed to boo_gold and boo_XXXX_gold

   apply(M,F,A) is transformed to

   foo_2.3.4:apply_xform(M, F, A)

   were foo:apply_x is a local function which

   dynamically transforms inter-module calls to the correct namespace

	       - o O o -

Rule 5

The /ebin directory contains compiled code from /xsrc



1) I have shown how to provide multiple namespaces with
   code transformation - the same think can be achieved internally
   by tinkering with the loader and run-time system

2) Dubugging function names may not look so nice
   So while debugging once might wish to run with
   no name translation

3) <<Challenge to Refactorers>>

   There seems to be great opportunities for code refactoring here

   The way I work is to work with some version of a program


   Then when it works make a snapshot and copy everything to App-2.4

   When App-2.4 works and I start with App-2.5 I would like to ask

   "what are the changes between App-2.3 and App-2.4" -

   Can knowledge of the changes be used in compilation to minimise
   the object code size if I want to run both versions in the same
   namespace (using some kind of transformation strategy)

  Indeed if I take multiple versions of an application and
  transform them how can I minimise the total size of the
  application, while having the same external interface.

  Here we would transform a tree like


  So that after the transformation the only visible modules would be


  And all the "internal" modules would have been merged/consolidated
a minimal set.

4) Question to those who know

   (ie Richard)

   Can igor, and the module namespaces do this already????



More information about the erlang-questions mailing list