[erlang-questions] Request for comment: A proposal to introduce the concept of function domains

[Thomas Järvstrand]

Hi all,

I write this email to get the community's opinion on an idea to extend
Erlang with the concept of function domains. The intention is for the end
result to be submitted as an EEP.

The rationale is that encapsulation is a good thing and that code should
not be allowed to depend on library functions that the library's author did
not intend to expose to the outside world. Because of this I would like to
introduce the idea of exporting functions into different domains.

There will be three predefined function domains: one will allow the
function to be called from anywhere, one will allow the function to be
called from within its own application and one to  disallow the function
from being explicitly referenced anywhere outside its module (this is for
behaviour callbacks, functions passed/returned as funs etc.)

To allow for extension in the future, compilation will allow any atom to be
given as the domain name (warnings could be added for non-predefined
domains), but xref will only be extended with processing of the predefined
domains.

Suggestions for what to call the predefined domains are:

*public, restricted, private*
The rationale is that due to how the language works, a domain-declaration
will only specify where we allow the function to be referenced with its
fully qualified name we can't detect other any other references anyway.
*
external, internal, restricted*
The rationale is that functions in the private domain are not really
private at all since they can be called from anywhere (eg. the handle_call
of a gen_server will be called from the gen_server-module). Private the
becomes restricted, because that's what it really is and we use the duality
of
external/internal for allowing calls from outside/inside the application.
The main issue with this suggestion is that many people associate internal
with non-exported functions.

I have two suggestions for how the domains should be declared in a module,
they are both attributes that take two arguments: the domain and a list of
<function>/<arity>:

*The domain/2 attribute:
*
Pros: Backwards compatibilty
Cons: "Clutters" the attribute namespace. Requires information to be duplicated
in the module (need both export and domain)

*The export/2 attribute:
*
Pros: Avoids cluttering the attribute namespace and avoids duplicated
information in the code.
Cons: Breaks backwards compatibility with earlier OTP releases for code written
using the new attribute.

I would appreciate some input on this, both from the community and the OTP
-team.

Regards
Thomas Järvstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130425/f2d3719c/attachment.htm>