[erlang-questions] Re: Parameterized module idioms

[Jayson Vantuyl]

> For example, [unless you're doing some crazy rewriting tricks] it's
> obvious which function this is calling:
> 
>    some_module:echo(E, "hello")
> 
> This isn't so obvious:
> 
>    E:echo("hello")
> 
> Here you have to trace back to the definition of E to find out what
> module it refers to.
Actually, that's the point.  There are two good reasons to do this.

1.  Hide massive amounts of information.

While this runs counter to your point, sometimes there's so much state data that it makes code impossible to maintain if you explicitly write it all.  This neatly hides it.  More to the point, Erlang already does this with records.  They allow you to pick and assign bits of the state without seeing it all.  You still have to trace the definition back to the record.  I don't really see this as different.

2.  Polymorphism

This is the big win.  E might refer to any number of classes which are instantiated in any number of actual combinations.  But another way, imagine that you separated this out into different types.  Then the call would be:

> T:echo(E,"hello")


This isn't nearly as nice as:

> E:echo("hello")


In this case, E holds all of the state, including the module.  This is no different than gen_server and friends.  It just considers the callback module to be part of the state, bundles them together out of side, and gives a reasonably short syntax to show them.  In practice, I don't think this is that hard to debug--especially in the cases where it yields shorter, simpler code.

-- 
Jayson Vantuyl
kagato@REDACTED