Thoughts about CEAN/refactoring

[Joe Armstrong (AL/EAB)]

 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:

   myAPP-2.3.4
   myAPP-1
   myApp-gold
   myApp-beta2

>>

Rule 2
======

We have One source code tree:

   Root/foo-1.2.3/Dependencies
		 /src/
		 /ebin
		 /xsrc
       /foo-gold/Dependencies
		/src
	        /ebin
		/xsrc
       /yaws-super-fast/Dependencies
		       /src
		       /ebin		   
		       /xsrc

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
"Dependencies".

Let's assume that the file 
      
      foo-2.3.4/Dependencies

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

 

Comments:

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

   App-2.3

   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

  foo-1.2.3/src/...
  foo-beta3/src/...
  boo-8/src/

  So that after the transformation the only visible modules would be

  foo_1.2.3.erl
  foo_beta3.erl
  boo_8.erl

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

4) Question to those who know

   (ie Richard)

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

Cheers

/Joe