Extending Functionality: gen_server_ext

[Jay Nelson]

martin j logan wrote:
 >This whole notion feels distinctly un-erlang. Erlang is simple,
 >straight forward and fairly consistent, that is what makes it great.
...
 >While the ideas that are expressed in this thread are quite
 >interesting and have much merit I think that they would serve
 >to undermine erlangs greatest strength - simplicity.

Eric Newhuis wrote:
 >I agree.

I am interested in hearing what makes you say that.  I am
wrestling with ideas and thinking out loud, so any reactions
are extremely helpful in reformulating my opinions.

I have proposed no change to the language and no change
to the way an erlang process operates.  Where my goals differ from
Chris' goals is that I am new to having cheap, easy processes
and would like to exploit them to their fullest (he may already
be beyond that by a couple orders of magnitude in the number
of processes and is thinking of other things).  I believe that
writing a very simple process, with almost no error checking,
has great advantage.  I would rather waste processes than
waste programming time and effort struggling with the mundane
aspects of a program.  I want to spend my time thinking of the
system level integration, throughput, distribution and limits
rather than which functional decomposition is correct.

My discussion centered on the communication mechanisms
among processes, considering these alternatives:

1)  a  <-->  b  <-->   c  <-->  d  <--> user

2)
a  <---->|
b  <---->| <-->  d  <--> user
c  <---->|

where each of a, b, c and d are processes.  I was proposing
that #2 is a richer model, #1 can be used on the back end of
a, b, and c, that a, b, and c can be dynamically added and
removed from d (consider that d is a UI textbox process and
that c is the 'editable' set of behaviours -- if it is not present the
textbox is not editable).

Vlad wrote:
 >Potential problem: how to ensure that these behaviours do not
 >have overlapping interfaces? (i.e. message tags or callback
 >names that are the same)

This is a good and fundamental question that is right on the mark.
What I am trying to propose is a method for code reuse that does
not bind up discrete, rigid, pre-architected objects into a monolithic
application.  Each process is closer to an abstract datatype than an
object (but I still refrain from making that assumption).

In my earlier post on uses of processes I mentioned:
 >3) Code reuse / abstraction / adapting interfaces.

Process d in #2 above abstracts the gen_server interface to the
user.  It *also* abstracts the gen_server interface to the backend
processes.  a,b,c and have no higher level knowledge, d contains
higher level knowledge and that is why I correlated it to a supervisor
rather than a gen_server; it acts like a gen_server but it is init'ed
and controlled like a supervisor with dynamic children.

If any of the backend process have overlapping interfaces, the
task of building an instance of d includes interjecting 'shim'
processes to eliminate ambiguity in message passing.  The
author of a,b,c cannot anticipate the places where they may
be used; the author of d does not have access to modify the
internals of a,b,c because that will break other code that relies
on them.  Instead he might introduce a new process 'e' which
transforms messages coming from b and c so that they are not
ambiguous to d.  This approach encourages having a,b,c do exactly
what they are intended to do and nothing more or nothing less,
without requiring d to introduce message disambiguation code which
detracts from algorithms d is really concerned with implementing.
e becomes one of your extremely simple erlang processes that
are easy to test and easy to see when they are not implemented
correctly (the process fails and communications break down).

The integrator rummages through the process toolbox and at
runtime declares which tools are bound together in which way
to get the desired results.

jay