[erlang-questions] Request for comment: A proposal to introduce the concept of function domains

[Robert Virding]

There is already an EEP which touches on this, http://www.erlang.org/eeps/eep-0005.html 

Robert 

----- Original Message -----

> 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 d omain/2 attribute :
> 

> > Pros : Backwards comp atibilty
> 

> > Cons: "Clutters" the attribute namespace. Requires information t o
> > be
> > duplicated in the module ( need both export and domain )
> 

> > Th e export/2 attribute:
> 

> > Pros: Avoids cluttering the attribute namespace and avo ids d upl
> > icated information in the code.
> 

> > Cons: Brea ks b ackwards compatibility with earl ier OTP releases
> > for
> > code w ritten using the new attribute.
> 

> > I would app reciate some input on this, both from the comm unity
> > and
> > the OTP -team.
> 

> > Re gards
> 
> > 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/20130426/cfe739fb/attachment.htm>