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

Björn Gustavsson <>
Mon Oct 8 14:15:06 CEST 2012

On Sun, Oct 7, 2012 at 12:32 PM, Tomas Morstein <> wrote:
> Hello,
> We wanted to upgrade our development environment to R15B02
> and ended up with a problem of different inheritance behaviour:
>   https://gist.github.com/3846164
> The point is simple, let's imagine scenario:
> - standard module a.erl with several core functions
>   (acts like abstract class)
> - parametrized module b.erl that extends a.erl
>   to bring all the a's functionality
>   (b has always a single parameter what is proplist)
> On older version of Erlang/OTP, this worked fine
> and we were able to b:new ([]) what gave us {b, []}.
> This does not work on R15B02 anymore :-(
> We don't want to make a.erl parametrized for many reasons,
> but I understand it makes some sense to bring a "base" (a)
> instance with the instance of b.
> The new behaviour still conforms to Richard Carlsson's paper,
> because our scenario was not presented there...
> The problem I see is that only the case of non-parametrized
> BASE "class" has changed in R15B02...

The change is this bug fix:


It is correction for a bug that was introduced three years
ago in this commit:


Had parameterized modules been a supported feature, we
would most probably have have test case that would have
made the breakage visible.

> How many changes are expected in future? Is it safe
> to believe that once we refactor the code, no future version
> will change something else?

No, that is not safe assumption for any experimental feature.
An experimental feature may changed or removed at any
time if it turns out to be a bad idea, or cause more problems
than it solves, or that a proper implementation would need
too much effort and too many other changes.

> Should we think about an alternative of doing inheritance
> in our custom way otherwise?

Yes, I would recommend that.

We (the OTP team) has not reached a decision yet, but it
does seem that the problems outweigh the advantages. This
email lists some of the problems:



Björn Gustavsson, Erlang/OTP, Ericsson AB

More information about the erlang-questions mailing list