Thoughts about CEAN/refactoring

Thomas Lindgren thomasl_erlang@REDACTED
Thu Jul 6 12:45:14 CEST 2006

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

Note that you will have to handle a couple of corner

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.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the erlang-questions mailing list