[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.

Thomas

2013/4/27 Thomas Järvstrand <tjarvstrand@REDACTED>

> @Lukas:
> 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.
>
> @Robert
> 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.
>
> Thomas
>
>
> 2013/4/26 Robert Virding <robert.virding@REDACTED>
>
>> There is already an EEP which touches on this,
>> http://www.erlang.org/eeps/eep-0005.html
>>
>> Robert
>>
>> ------------------------------
>>
>> *From: *"Lukas Larsson" <lukas@REDACTED>
>> *To: *"Thomas Järvstrand" <tjarvstrand@REDACTED>
>> *Cc: *"Erlang" <erlang-questions@REDACTED>
>> *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?
>>
>> Lukas
>>
>>
>> On Thu, Apr 25, 2013 at 9:21 AM, Thomas Järvstrand <tjarvstrand@REDACTED
>> > 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
>>> 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
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130427/51adb3a8/attachment.htm>