Calling internal functions - foo::bar() ?
Mon Mar 7 20:36:12 CET 2005
"Thomas Lindgren" <> replied to my post:
> > > Introducing :: may, as you say, still be a bad idea.
> > Indeed it is. A very bad one in fact.
> Given the prevalence of export_all all the way to
> deployed code, there still seems to be a customer, er,
> developer need for this sort of functionality :-)
Just in case some of my points were too implicit, let me make them
Most of us agree that "export_all" is a terrible kludge, but some
feel that is is occasionally helpful in developing/debugging.
However bad it may be, note that at least it has the property that
it allows the compiler to optimize internal functions in modules
that do NOT contain an "export_all". This is something detectable
at compilation time (i.e., when the .beam file is generated) and
trivially also detectable by using "grep".
The BEAM/native code code compiler is thus allowed to say: "Aha, the
programmer has used an export_all in this module; I will punish her
by not performing any optimizations in that module, and will only
optimize the internal functions in the rest of her modules."
The latter is possible _because_ there is currently no construct to
call internal functions.
In the presence of a :: construct, no sophisticated optimizations
are possible to perform without having a fall-back mechanism.
This puts an unnecessarily big implementation effort to the compiler's
optimizer and significantly increases the size of the generated .beam
Good that the OTP team opted against it.
More information about the erlang-questions