[erlang-questions] Re: Will parameterized modules become an official part of Erlang?

[Fred Hebert]

My opinion on parametrized modules was formulated in this stackoverflow
post:
http://stackoverflow.com/questions/2291155/what-alternatives-are-there-to-parameterised-modules-in-erlang/2291394#2291394--
I won't say much more on this.

I don't have much of a problem with -extend() myself, though. It permits a
very flat inheritance to modules, which can sometimes be useful. The
overriding rules are simple (if it's the same function, it replaces it,
otherwise, it looks in the extended module), there can only be one extended
module at once, etc.

It's useful when you want to add specificity on top of another module
without wanting to redefine everything else. I guess the simplest example
could be about a module made to work on a deck of cards: depending if they
are UNO cards, regular cards or let's say Pokémon cards, the functions to
initiate a deck or to verify its integrity will vary from implementation to
implementation, but will remain similar for everything else (shuffle,
distribute, add/remove cards, etc).

One of the downsides I see is that the dispatch seems to be made at runtime
(module_info/0 returns no information about extended modules' functions),
which means that the extended module's internal representation might change,
provoking errors in the extender without much warning. It's a breach of
encapsulation to some extent.

It's easy to argue that a callback module with a behavior would be much more
appropriate. Not only does it solve the problem mentioned in the previous
paragraph (the behavior needs to be compiled itself, there are fewer
ambiguities, etc.), but it is consequent with the development concepts
proposed by the OTP framework.

On Sun, Feb 21, 2010 at 8:25 PM, Robert Virding <rvirding@REDACTED> wrote:

> I would like to extend the question to two other things which have
> been "experimental" for a while now without being decided or having
> proper documentation:
>
> - the -extends attribute
> - packages
>
> The trouble is that they are "there" but it is not defined what they
> do and you can't turn them off so it is easy to get bitten by them and
> not really understand what has happened. And how do they interact?
> Yes, I do know of the papers describing two of them but no one can say
> it is obvious that you look there for Erlang documentation.
>
> To start the discussion rolling here are my opinions on the three
> listed in order of *decreasing* approval/interest or increasing
> disapproval:
>
> - Paramterised modules - I can live with these but don't really see
> the point yet.
> - Extends: sub-moduling?
> - Packages: a hierarchical peg in a flat hole, I just don't think its fits.
>
> Comments?
>
> Robert
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>