Thoughts about CEAN/refactoring
Thu Jul 6 12:45:14 CEST 2006
--- "Joe Armstrong (AL/EAB)"
> Now we transform the code as follows:
> all module names
> foo foo_XXXX are transformed to foo_2.3.4
> bar bar_XXXX are transformed to bar_7.0 and
> boo boo_XXXX are transformed to boo_gold and
> 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
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