<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/25/2013 12:21 AM, Thomas
Järvstrand wrote:<br>
</div>
<blockquote
cite="mid:CALbb2wFa=GxvT47FHSzDSdtGY-52AnUT19o3fb4i+GhLGx73Lg@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">
<div class="gmail_default">
<div>
<div>Hi all,<br>
<br>
</div>
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.<br>
<br>
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.<br>
<br>
</div>
<div>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.)<br>
<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Suggestions for what to call the predefined domains are:<br>
<br>
</div>
<div><b>public, restricted, private</b><br>
</div>
<div>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.<br>
<b><br>
external, internal, restricted</b><br>
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<br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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>:<br>
</div>
<div><br>
</div>
<div><b>The domain/2 attribute:<br>
</b></div>
<div>Pros: Backwards compatibilty<br>
</div>
<div>Cons: "Clutters" the attribute namespace. Requires
information to be duplicated in the module (need both export
and domain)<br>
<br>
</div>
<div><b>The export/2 attribute:<br>
</b></div>
<div>Pros: Avoids cluttering the attribute namespace and
avoids duplicated information in the code.<br>
</div>
<div>Cons: Breaks backwards compatibility with earlier OTP
releases for code written using the new attribute.<br>
<br>
</div>
<div>I would appreciate some input on this, both from the
community and the OTP-team.<br>
</div>
<div><br>
</div>
<div>Regards<br>
Thomas Järvstrand<br>
</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
I think that function domains touches upon a related issue, which
could hopefully be combined into one EEP. The issue is a lack of
module namespaces, which currently impacts application
dependencies. Ignoring any potential use by the developer of a
namespace concept, and definitely ignoring the past packages
implementation that has since been removed from Erlang, there exists
an application dependency problem which limits the growth and
flexibility of Erlang systems. The problem is that if application A
and application B both depend on C, but on different versions of C,
it is difficult to include both A and B without modifying one of
them. The idea of function domains can help provide some access
control of a module within the context of a single application,
however, access control is a larger problem which impacts how
applications can be combined. To make Erlang more flexible for
integrating with various open source dependencies, and various
legacy code dependencies, it is often not realistic to build the
release with only a single version of a specific application
dependency. I think having the version optionally be added to all
of the module names (as a suffix) within an application, which is a
problematic dependency, is a way of coping with the issue (it could
be based on a flag within the application file of the dependency),
but I am sure there are other solutions which may be better. Either
way, both emails deal with the concept of access control for Erlang
source code.<br>
<br>
- Michael<br>
</body>
</html>