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

[Ulf Wiger]

The -extend() function ought to fit perfectly for defining
mnesia activity callbacks. The mnesia_access behaviour has a
daunting number of functions. Most of the time, when I feel the
need for a mnesia_access callback, there are only a few functions
that I feel the need to extend (or at least, that's how one would
like to start out).

Interestingly, there is no module called mnesia_access. The default
callback module is mnesia. I assume this is a bit tricky to change
after so many years, but a first step could be to move all the
callback functions out of mnesia.erl and into mnesia_access.erl,
then keep mapping functions in mnesia.erl, to serve those who have
hard-coded mnesia as their activity callback.

This would allow people like me to write an activity callback that
extends mnesia_activity using the -extend() attribute.

BR,
Ulf W

Fred Hebert wrote:
> 
> 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.

-- 
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com