export_to (Was: Re: the OO metaphor)
Fri Dec 1 13:33:44 CET 2000
On 1 Dec 2000, Luke Gorrie wrote:
>Could someone explain to me how in practice you actually get in
>trouble from not having export_to?
As you say, disciplined programmers don't get into trouble.
>I think that when I'm looking for a function, I either look in a
>manpage (where internal exports should be undocumented), or the
>exports in a source file. If I see a comment like "%% Internal
>exports", I know not to use them. I can't think of a case where I'd
>end up calling something that's not exported "for me".
I would think that it's more a matter of making it very explicit that
certain functions are only exported for a single purpose. Not only are
you not supposed to call them - you're not even able to.
In this way, it's similar to having an explicit -export(...) clause,
instead of just inserting comments like "%% internal functions".
>Maybe if you use module_info/0 for looking up functions you can get
>in trouble, but I guess most people only do that for throw-away use
>in the shell if at all.
Hehe, I'd like to see some code that actually does something useful by
calling module info, and then simply going through the list of
exported functions and calling them, just to see what would happen.
>So, is it some quick-hack temptation of "Hey, I could just call
>foo:handle_call(...) directly to do this!" that causes the problems,
>or is there some more accidental cause, or..?
I've seen direct calls to handle_call(...) just to reuse the
implementation, but they have been from within the same module, so
that doesn't apply here. It's still a hideous practice.
Ulf Wiger tfn: +46 8 719 81 95
Senior System Architect mob: +46 70 519 81 95
Strategic Product & System Management ATM Multiservice Networks
Data Backbone & Optical Services Division Ericsson Telecom AB
More information about the erlang-questions