<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><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><font><font>The d<font>omain/2 attribute<font>:<br></font></font></font></font></b></div><div><font><font><font><font><font>Pros</font>: <font>Backwards comp<font>atibilty<br>
</font></font></font></font></font></font></div><div><font><font><font><font><font><font><font>Cons: "Clutters" the attribute namespace. Requires information t<font>o be <font>duplicated in the module (<font>need both export and domain<font>)</font></font></font></font></font><br>
<br></font></font></font></font></font></font></div><div><b><font size="4"><font>Th<font>e </font>export/2 attribute:<br></font></font></b></div><div><font>Pros: Avoids cluttering the attribute namespace<font> and <font>avo<font>ids d<font>upl<font>icated information in the code.<br>
</font></font></font></font></font></font></div><div><font><font><font><font><font><font>Cons: Brea<font>ks b<font>ackwards compatibility with earl<font>ier OTP releases</font> for code w<font>ritten using the new attribute.<br>
<br></font></font></font></font></font></font></font></font></font></div><div><font><font><font><font><font><font><font><font><font>I<font> would app<font>reciate <font>some</font> input<font> on this, both from the comm<font>unity and the <font>OTP<font>-team.</font></font></font></font></font></font><br>
</font></font></font></font></font></font></font></font></font></div><div><font><font><font><font><font><font><font><font><font><br></font></font></font></font></font></font></font></font></font></div><div><font><font><font><font><font><font><font><font><font><font>Re<font>gards<br>
<font>Thomas Järvstrand</font><br></font></font></font></font></font></font></font></font></font></font></font></div><div><font><font><font><font><font><font><font><font><font><br></font></font></font></font></font></font></font></font></font></div>
</div></div>