Extending Functionality

[Chris Pressey]

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
explicit).

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...

-Chris


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