Thu May 2 10:01:41 CEST 2002
> a) Things may load slowly
> b) It becomes increasingly difficult to ship stand-alone
> applications since nobody is really sure of what code is needed.
> A consequence of c) is the *ship everything* mentality.
> I'm going to take a good hard look at the system to see if we can't
>identify a minimal kernel ...
If I may add my humble opinion, this is why having a "-uses([module])." or
similar would help - by making the relations between modules explicit. This
might even encompass applys with variable arguments - only calls to listed
modules will be allowed.
I think that not shipping everything is not necessarily good - what if one
later loads new code that relies upon some less used stdlib module? One
should have then to keep track of what was delivered where, and it is
difficult in the long run even for such hard constrained environments as
Ericsson's. Also, what if an operator might be allowed to access the Erlang
shell - he/she wouldn't have access to the absent functionality...
However, should one be sure that the code base is fixed or the whole system
will be upgraded, then it is also possible to have an additional step after
the compilation, where all unused modules (maybe even functions) can be
removed from the delivery. Of course, this is not trivial without things
like "-uses([module])." or "-uses([mod:fun/x]).".
just some thoughts. Regards,
Skicka och ta emot Hotmail-meddelanden på din mobilenhet:
More information about the erlang-questions