Extending Functionality

Chris Pressey chris_pressey@REDACTED
Fri Mar 21 22:57:27 CET 2003

Shawn Pearce wrote:

> Chris, I think Matthias' concern was more related to overloading
> the undefined_function behavior in error_handler, or some similiarly
> abstract way of making a function call.  Even my -inherit() and
> dispatch function I proposed would fall here, as it makes the code
> signifcantly harder to follow.  At least now you can lookup module
> foo, locate the definition of bar and see it calls baz:quuz(),
> and recurse.  :)

Yes... I took it as a general comment, since gen_server_ext falls here
too (next_call makes the redirection from one module to another less

The rule of thumb I'm using here is: the easier it is to write code in
layers, the harder it will be to follow the code.

On one extreme you have OO-maniacs valuing the ease of writing code in
layers (inheritance) above all else, under the mistaken impression this
will lead to infinite code reuse that will save everyone lots of time
and money in the future.

On the other extreme you have OO-phobics reinventing the wheel because
it's quicker and/or more efficient to rewrite it (in Erlang, anyway)
than to locate existing code that does exactly what they want.

The only important question (to me) is where the maintainability of one
of these approaches eclipses the maintainability of the other.

Based on history I don't doubt the optimal point is closer to the
OO-phobic end of the scale, but at the same time it would feel wrong to
settle on the status quo - we have to keep experimenting and looking
for a more optimal point, if only to fatten the accumulated body of
knowledge about *why* alternate approaches to reuse don't provide any
benefits over what we already use...


Post your free ad now! http://personals.yahoo.ca

More information about the erlang-questions mailing list