[erlang-questions] Is -extends() used in any projects?
Yurii Rashkovskii
yrashk@REDACTED
Wed Jan 23 03:04:21 CET 2013
What's interesting, using metaprogramming techniques available in Elixir,
we can do a much better `-extend()` kind of functionality in Elixir:
```
defmodule M do
defmacro __using__(_opts) do
quote do
def hello_world, do: "Hello, world!"
end
end
end
defmodule A do
use M
end
defmodule B do
use M
end
```
Now, both modules A & B have the same shared hello_world/0 function and
it's always exported, and A & B are completed decoupled from M after the
compile cycle:
```
iex(1)> A.hello_world
"Hello, world!"
iex(2)> B.hello_world
"Hello, world!"
iex(3)> A.module_info(:exports)
[__info__: 1, hello_world: 0, module_info: 0, module_info: 1]
iex(4)> B.module_info(:exports)
[__info__: 1, hello_world: 0, module_info: 0, module_info: 1]
```
On Tuesday, January 22, 2013 5:55:04 PM UTC-8, Robert Virding wrote:
>
> I agree as well! I think being able to see clearly see what functions a
> module exports is a rule which we should always follow.
>
> Robert
>
> ----- Original Message -----
> > From: "Loïc Hoguin" <es...@REDACTED <javascript:>>
> > To: "Richard O'Keefe" <o...@REDACTED <javascript:>>
> > Cc: "erlang-questions" <erlang-q...@REDACTED <javascript:>>
> > Sent: Wednesday, 23 January, 2013 2:29:55 AM
> > Subject: Re: [erlang-questions] Is -extends() used in any projects?
> >
> > On 01/23/2013 02:09 AM, Richard O'Keefe wrote:
> > >
> > > On 22/01/2013, at 7:44 PM, Björn Gustavsson wrote:
> > >
> > >> -extends() was mentioned when we first talked
> > >> about removing parameterized modules, so we
> > >> assumed that we needed to emulate -extends()
> > >> as well as parameterized modules.
> > >>
> > >> It seems to be a good time to ask the question:
> > >>
> > >> Is -extends() used by real projects? Do we really
> > >> need to emulate it?
> > >>
> > >> BTW, -extends() is described here:
> > >>
> > >> http://www.erlang.se/euc/07/papers/1700Carlsson.pdf
> > >
> > > I believe that the design described there takes a wrong
> > > step on the very first non-title slide:
> > >
> > > All function calls to new_module:f(...)
> > > will be redirected to old_module:f(...)
> > > if f is *NOT* exported from new_module.
> > >
> > > I think that the rule "you may call m:f/n from
> > > another module if and only if m explicitly
> > > exports f/n" is an excellent rule.
> > >
> > > It means that if you want to know what are the things
> > > in module m, the information is right there in the
> > > source code and the beam and if it is loaded,
> > > module_info gives it to you.
> > >
> > > With the design described in those slides, YOU NEVER
> > > KNOW WHAT THE INTERFACE OF A MODULE (that has an
> > > -extends in it) IS.
> > >
> > > If you *don't* break the module-interfaces-are-knowable
> > > rule, you get a different design which is entirely
> > > compile-time (and thus faster):
> > >
> > > If f/n is -exported
> > > and f/n is not defined
> > > and there is an -extends(m)
> > > then generate a glue definition
> > > f(A1,...,An) -> m:f(A1, ..., An).
> > >
> > > It's simple.
> > > The full interface of a module remains discoverable.
> > >
> > > And it's *faster*, because the current design
> > > requires the lack of a definition to be detected at
> > > run time, a trap out to a special handler (with the
> > > arguments packaged into a data structure), time to
> > > figure out what was undefined, the arguments have to
> > > be unpacked again, and finally what would have been
> > > the body of the glue definition is executed.
> > > To quote Jayne, "where does that get to be fun?"
> > >
> > > I once wrote a paper that I couldn't get published.
> > > It described an object oriented extension to
> > > Intercal, and it was as deliberately perverse as
> > > plain Intercal.
> > >
> > > This particular attempt to turn Erlang into an OO
> > > language reminds me very much of that paper, only
> > > it isn't funny when it's real.
> > >
> > > I've built a Smalltalk implementation. Now Smalltalk
> > > was originally a single-inheritance language, and its
> > > dynamic typing means that there are fewer constraints
> > > on what you can do that way than there are in typical
> > > typed OO languages. Even so, there is rather more
> > > code duplication than I am happy with, and it may be
> > > this year that I finally add mixins. (Or it may not.
> > > There are enough other things to worry about.) Why
> > > mention that here?
> > >
> > > Because the way -extends is presented in that paper
> > > means that it can only support single inheritance.
> > > (Since the ability to determine a module's full
> > > interface has been destroyed, it cannot handle
> > > -extends(p).
> > > -extends(q).
> > > by checking which of p, q defines f/n.) And that's
> > > an unjustified limitation.
> > >
> > > Change it slightly. Instead of -extends, use
> > >
> > > -export_from(Other_Module, Export_List).
> > >
> > > That's just a handy abbreviation form.
> > > -export_from(m, [...,f/n,...]).
> > > means
> > > f(A1, ..., An) -> m:f(A1, ..., An).
> > >
> > > And now you have multiple inheritance.
> > > And you have better compile-time checking: things
> > > are not re-exported *implicitly*, so if an
> > > -exported function is not defined in *this* module,
> > > that's still an error.
> > >
> > > And the good part is that because a module's full
> > > interface is discoverable, you can point your text
> > > editor at a .beam file and say "generate me a
> > > -export_from directive from _that_." (Which should
> > > be done by calling a little command-line tool:
> > > generating an -export_from directive doubles very
> > > nicely as a way for a human to find out what a module
> > > exports without having to read the source code, which
> > > they might not have anyway.)
> >
> > Agree with everything.
> >
> > Thanks ROK for always making amazingly clear explanations.
> >
> > --
> > Loïc Hoguin
> > Erlang Cowboy
> > Nine Nines
> > http://ninenines.eu
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-q...@REDACTED <javascript:>
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@REDACTED <javascript:>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130122/37152bf1/attachment.htm>
More information about the erlang-questions
mailing list