export_to (Was: Re: the OO metaphor)

[Richard Carlsson]

On Fri, 1 Dec 2000, Thomas Lindgren wrote:

> In a similar vein to "export_to", I'd like to have something like
> this:
> 
> -export([...]).  %% functions visible outside the module
> -apply([....]).  %% functions that can be metacalled
> -spawn([....]).  %% functions that can be spawned
> 
> The "internal exports" would show up in -apply or -spawn, but not in -export.
> Some shorthand could be provided as well 
> (-compile(export_all) = export+apply+spawn?).
> 
> 			Thomas

This should not be needed, since you can nowadays write:

	spawn(fun () -> my_nonexported function(X1, ..., Xn) end)

There should now be no reason to export a function name that is not
expected to be called from other modules. (Counterexamples, anyone?)

Furthermore, I think it is a mistake to introduce an "export to"
declaration, because it requires of the programmer to foresee the future
uses of his module. It is one thing to, as in most OO languages, be able
to limit the use of a function (method) to a specific *category" of other
modules: those in the same class, or those in the same package, etc. But
consider the problem in C++ when a function has not been declared as
virtual, making it impossible to use dynamic method binding in a future
application. Of course, C++ has "friend" declarations, which is analogous
to the "export_to" idea, but I find it doubtful whether they are really
motivadet considering the above problem - Java for instance does fine
without "friends".

	/Richard Carlsson


Richard Carlsson (richardc@REDACTED)   (This space intentionally left blank.)
E-mail: Richard.Carlsson@REDACTED	WWW: http://www.csd.uu.se/~richardc/