<div dir="ltr"><div>Correction: private functions may be of course be referenced from inside their own module.<br><br></div>Thomas<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/27 Thomas Järvstrand <span dir="ltr"><<a href="mailto:tjarvstrand@gmail.com" target="_blank">tjarvstrand@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>@Lukas:<br></div>There is actually no need need to introduce the concept of applications into the language itself, merely support for the notion of different types of exports. Interpreting the meaning of these exports can be left to xref, which already has support for applications.<br>
<br></div>The point of the private type of export is for functions that have to be externally callable, but that should never be explicitly referenced. Examples of this are behaviour callback functions (such as the handle_call etc. of a gen_server) and functions that are passed to or returned from functions calls (such as spawn). Ie, they are functions that may only be implicitly referenced (ie. in the calling code, either the module, the function name or both would have to be a variable). Basically this means that any calls to private functions that xref is able to detect are illegal.<br>
<br></div>@Robert<br></div>Yes, I'm aware of that EEP. It has similar aims and looks cosmetically similar but the suggestion to limit access on a module level would make things awfully messy IMHO. With EEP 5, you have to clutter your code with individual exports for every single caller/callee-pair inside your application. If you want to call a new function in your module, you would now have to edit two files instead of one. A more serious flaw though is that if you're writing a utility library that is to be used by others, you have no idea who will be calling your module, and so you cannot export your functions to them.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></div><span class="HOEnZb"><font color="#888888">Thomas<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/26 Robert Virding <span dir="ltr"><<a href="mailto:robert.virding@erlang-solutions.com" target="_blank">robert.virding@erlang-solutions.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:12pt;font-family:times new roman,new york,times,serif">There is already an EEP which touches on this, <a href="http://www.erlang.org/eeps/eep-0005.html" target="_blank">http://www.erlang.org/eeps/eep-0005.html</a><br>
<br>Robert<br><br><hr><blockquote style="padding-left:5px;font-size:12pt;font-style:normal;margin-left:5px;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal;border-left:2px solid #1010ff"><b>From: </b>"Lukas Larsson" <<a href="mailto:lukas@erlang-solutions.com" target="_blank">lukas@erlang-solutions.com</a>><br>
<b>To: </b>"Thomas Järvstrand" <<a href="mailto:tjarvstrand@gmail.com" target="_blank">tjarvstrand@gmail.com</a>><br><b>Cc: </b>"Erlang" <<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>><br>
<b>Sent: </b>Friday, 26 April, 2013 8:57:03 AM<br><b>Subject: </b>Re: [erlang-questions] Request for comment: A proposal to introduce the concept of function domains<div><div><br><br><div dir="ltr"><div>Hello Thomas,<br>
<br></div><div>I agree that there is a need for better encapsulating possibilities in Erlang. However in order to allow calls only within the current application you have to introduce the concept of an application into the language and not only in OTP. Personally I think having language support for a collection of modules (like packages in Java, or namespace in C++) is a necessity for the language to grow and mature. I do however not know what that would look like and what properties that would bring. Have you thought anything about this?<br>
<br></div><div>I also do not really understand the purpose of private. How does it differ from not-exported? Is it an exported function which can only be called from a specific behaviour module? <br><br></div><div>Lukas</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 9:21 AM, Thomas Järvstrand <span dir="ltr"><<a href="mailto:tjarvstrand@gmail.com" target="_blank">tjarvstrand@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><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<span><font color="#888888"><br>
<font>Thomas Järvstrand</font><br></font></span></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>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote><br></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>