[erlang-questions] Request for comment: A proposal to introduce the concept of function domains
Sat Apr 27 13:11:34 CEST 2013
Correction: private functions may be of course be referenced from inside
their own module.
2013/4/27 Thomas Järvstrand <>
> 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.
> 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.
> 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.
> 2013/4/26 Robert Virding <>
>> There is already an EEP which touches on this,
>> *From: *"Lukas Larsson" <>
>> *To: *"Thomas Järvstrand" <>
>> *Cc: *"Erlang" <>
>> *Sent: *Friday, 26 April, 2013 8:57:03 AM
>> *Subject: *Re: [erlang-questions] Request for comment: A proposal to
>> introduce the concept of function domains
>> Hello Thomas,
>> 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?
>> 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?
>> On Thu, Apr 25, 2013 at 9:21 AM, Thomas Järvstrand <
>> > wrote:
>>> 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
>>> 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
>>> 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
>>> Thomas Järvstrand
>>> erlang-questions mailing list
>> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions