[erlang-questions] (Non)Parametrized modules, inheritance, and R15B02 issues?

Tomas Morstein tmr@REDACTED
Wed Oct 10 00:54:21 CEST 2012


> > Is there a good write-up on parameterized module alternatives
> > anywhere?
> > 
> > - always include an .hrl and pass a record instance as arg 1 ?
> > 
> 
> It depends on what exactly you are using them for.
> 
> Personally, I would define a fun with two args, where the first
> argument
> is a method name and the second argument is a tuple with the
> arguments.

I like this idea, it's clean and elegant, but not without limitations :(

The problem starts when it comes to projects like ChicagoBoss
that we at IDEA love and intensively use every day.
CB uses pmods not only for simple_bridge-based web controllers,
but also for its sophisticated and well integrated concept of
data models being linked with Django templating engine in turn.

Although I fully understand reasons why pmods and their eventual
pseudo-OOP behaviour (like inheritance) are not so clear as they
are implemented today, but in other hand, many excellent projects
may disappear in final result...

I hope such a "total eclipse" is not going to happen, but our case
(over-using the extra unsupported and hackish features) we've just
adapted our technology to framework and totally forgot to standards,
what's in fact our own mistake.

Of course, once something is not well documented/specified/supported,
no one should use it seriously, so we accept the situation we ran into.

Another thing is that some functionality, especially the case of pmods,
is so popular, as everybody knows it because it is really useful,
that everybody also uses it. Pmods seems to be a "de facto" standard
then.
Shouldn't we pay attention since it's used so heavily on many places?

Please note that I am not in a position allowed to dictate nor
recommend anything. It's just a description of my point of view and
I'm pretty sure that no matter on the result of pmod "affair",
everybody will have to accept "new rules" finally (or move elsewhere).

Tom



More information about the erlang-questions mailing list