Extending Functionality: an expedient and questionable approa ch

[Vlad Dumitrescu (EAW)]

Hi guys,

I happen to know this Vlad person :-D and he likes to be the fool that
throws the stone into the lake and let 20 wise people try for a month
to figure how to pick it back.

My original idea, that Chris tested, has a major drawback (besides the
problems Chris and the others observed): it allows only for an unknown
function to be looked for in another module. This is fine, but is it
enough? Is it what is really needed? Many (most?) times the functions
that we'd like to extend have many clauses and it's probably so that
we'd like to be able to select specific clauses from different
modules.

Since this functionality may not be very useful for library functions,
but for processes, I think a better answer is to use my new
gen_server_ext behaviour, featuring:
	- a list of "ancestors" that will be checked for loops and
          rejected if any are found
	- modules will look just like regular gen_server modules
	- use of gen_server_ext:next_call() [_cast, _info, etc] that
          make it possible to go up the "hierarchy" in a controlled
          way, i.e.
		1) one can choose what functionality to reuse;
		2) the reuse is explicit = no surprises from
                   unexpected automatic handling
		3) and the designer has to think about what he/she's
                   doing
	- if the need should exist, the ancestor list may be made
          modifiable at run-time

All in all, my impression is that this is very close in effect to the
CommonLisp generic functions.

	<shameless_self_marketing>
	It's powerful, flexible, easy to use. And what's maybe most
	important: doesn't need to get any "OO" label, it is a natural
	extension to gen_servers! :-)
	</shameless_self_marketing>

Okay, I'm not saying this is the ultimate answer (because we all know
that's 42) but it may be the way to go and add improvements to. (I
already have some buzzing around...)

I will try to write some examples this weekend, hopefully some less
than the most trivial, but don't hold your breath.

Feedback is welcomed! Regards, 
Vlad