Extending functionality

[Vlad Dumitrescu (EAW)]

Good morning everyone,

I sat and thought about which way is best for extending existing functionality in Erlang, without touching the original source code. There are two issues (not sure if they are very different): extending a module's functionality and extending a process' functionality.

An example might be best: let's say I have found a way to improve the "strings" module, only some parts of it. Let's also suppose the source for "strings" isn't available. I would like to write a module called "better-strings" where my improvements are implemented, and what's unchanged should be directed to the regular "strings". This is because I don't want to be forced to remember which function is in which module when working with the strings. Later on, someone else might improve more stuff, but maybe some is from "strings" and some is from "better-strings" - and would like to write "even-better-strings" to transparently extend "strings" and "better-strings". 

A similar question can be applied to processes: I have a server and I'd like to add some functionality without recompiling it. The change might involve handling new requests and/or modifying existing request handling. It should work with plain servers and also with gen_servers. One example is instrumenting the server so that it logs every request made. 

There is also a third case: extending a function with more clauses, even if this function is defined in another module: generic functions. These I'm not sure if they are really useful alone, I took them here just for completness.

Is this a real problem, or am I just being too academic? How are these issues handled today? Any thoughts stirred by my questions will be appreciated.

I don't see any way that doesn't involve either writing plenty of functions that delegate to the other module(s) [with a lot of redundancy and error-prone], or changing the runtime and compiler in a non-trivial way. These extensions might also come in two different flavors: static (affecting the source code) and dynamic (run-time instrumentation), which will probably need to be handled in vey different ways.

best regards,
Vlad