export_to (Was: Re: the OO metaphor)

[Ulf Wiger]

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.

/Uffe
-- 
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