Thoughts about CEAN/refactoring

[Thomas Lindgren]

--- "Joe Armstrong (AL/EAB)"
<joe.armstrong@REDACTED> wrote:


> 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

This is basically the approach taken by my Erlang
optimizer, as described in EUC 2001 -- though there it
was used to specialize, merge, split, and optimize
modules.

Note that you will have to handle a couple of corner
cases:

1. Apply of apply   apply(erlang, apply, [M, F, As])
and so on.

2. The approach is 'insecure' in that someone can
build a module name on their own and invoke a 'hidden'
module with a raw apply. I'm agnostic whether this is
a good or bad thing. (The safe approach is to never
provide external access to the 'actual' apply.)

Regarding dead code after module merging: yes, this is
often present. However, do note that you will have to
be a bit careful not to accidentally delete live
functions :-)

Furthermore, if you merge modules, you will have to be
clever about changing/patching/hot-loading individual
modules inside a merged entity. Otherwise, you can
inadvertently hang on to a great deal of now-dead
code. This may be okay, of course.

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com