Extending Functionality: gen_server_ext

Shawn Pearce spearce@REDACTED
Fri Mar 21 20:24:15 CET 2003


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

One of the things I like about Erlang is just how simple it is.  It
only takes me 5 minutes to locate the definition of almost any system
function, even if it is down deep in the emulator's native C code.
That's hard to do in most other current 'high-level' programming
languages.  (I use the term 'high-level' loosely too.)


Lately I've been reading about just how flawed SQL databases are from
Codd's relational model introduced in '69.  I'm starting to feel the
same way about object oriented programming in general, and I'm just
hoping that the same tendenacies that caused programmers to build,
adopt and eventually believe that SQL databases are perfect, true
relational systems doesn't cause Erlang to grow into a simliar
type of system.


On the other hand, I just wrote a server for which I use two gen_server
processes to implement a TCP server.  (Like what was kicking around here
a week or two ago.)  Only I wanted support of both gen_tcp and ssl,
and in both passive and active modes (I use {active, once}).  Can we
say macros, include files, and just some weird magic to make it work?
Its not as bad as I'd feared (5 macros, 1 major source file, 2 module
files to set the 5 macros and include the major source file), but its
still not ideal.


Chris Pressey <cpressey@REDACTED> wrote:
> On Fri, 21 Mar 2003 12:31:32 +0100
> Matthias Lang <matthias@REDACTED> wrote:
> > Changing the meaning of a function call is not about changing OTP. It
> > is changing the language. You can no longer be sure that the code
> > executed by a call to foo:bar() can be found in the module foo.
> > 
> > That is a big new uncertainty.
> > 
> > Matthias
> 
> Is it really so new?
> 
>   -module(foo).
>   bar() -> baz:quuz().

-- 
Shawn.

  "I think trash is the most important manifestation of culture we have in my
  lifetime."
  - Johnny Legend



More information about the erlang-questions mailing list