[erlang-questions] Beginner Question: Spring-like IOC in erlang

[Jesper Louis Andersen]

On Wed, Apr 13, 2011 at 21:44, Todd Greenwood-Geer
<t.greenwoodgeer@REDACTED> wrote:
> 1. Is there an idiomatic way to use dependency injection in erlang?
>
> Most of my use of Spring DI has been to facilitate injection of test classes
> into a stack for functional testing. Is this sort of thing done in erlang?

Not very much, but it is possible. A module is just a term like
anything else, so you can do it either dynamically or by static
configuration in the test. Parameterized modules used as ML-style
functors can also provide you with the equivalent of dependency
injection.

> 2. How about AOP style join-points for before and after execution around a
> method?

There are much better tracing facilities in Erlang. Dynamic debugging
and tracing are built-in and you can also get something like "redbug"
from the eper suite which is particularly powerful. The ability to
carry out tracing on any production system is pretty cool.

> 3. Is there a way to intercept messages to a process? This is the real
> question... Say a process dies unexpectedly and OTP restarts it... it would
> be cool to be able to dynamically proxy messages to a process that has
> exceeded some error threshold. The proxy could log them, or perform more
> intensive error analysis... Then, once the system is back in a normal state,
> the proxy could be removed from the message loop chain.

The problem is that as soon as your code crashes or dies, you can't
really trust the messages that are residing in the queue at all. There
are tools which will give you a dynamic view of what is going on
inside the queue if you want, but it is usually more used in in the
debugging phase.

In general, the error-logging in Erlang will tell you the message
*and* the state that crashed the process. The reason we can tell you
the state is because data in Erlang is persistent. We just keep a
reference to the original state before we begin processing and then we
can report back to you if the process fails. It makes a lot of
tracking down why a given error happen much easier.

-- 
J.