export_to (Was: Re: the OO metaphor)

[Chandrashekhar Mullaparthi]

To me, it seems like the only advantage is that in a large project, some
programmer might disregard certain rules and call functions which are
"marked" internal exports. This might break the code when these internal
exports are removed/changed etc.

Though this might become a pain when you want to quickly test some function
and it is marked as an internal export. 

But I feel the same - it just doesn't seem terribly necessary.

> -----Original Message-----
> From: Luke Gorrie [mailto:luke@REDACTED]
> Sent: 1 December 2000 12:17
> To: Sean Hinde
> Cc: 'Ulf Wiger'; Vlad Dumitrescu; erlang-questions@REDACTED
> Subject: export_to (Was: Re: the OO metaphor)
> 
> 
> Sean Hinde <Sean.Hinde@REDACTED> writes:
> 
> > These sort of things would become much cleaner if we had 
> Richard O'Keefe's
> > idea of 'internal exports' (so for example the functions 
> currently exported
> > for gen_server callbacks wouldn't become part of the API).
> 
> Could someone explain to me how in practice you actually get in
> trouble from not having export_to?
> 
> 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".
> 
> 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.
> 
> 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..?
> 
> Cheers,
> Luke (who has some hazy recollection of having called a handle_call
>       directly, come to think of it.. :-))
> 



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.