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

[Björn Gustavsson]

On Sun, Oct 7, 2012 at 12:32 PM, Tomas Morstein <tmr@REDACTED> 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:

https://github.com/erlang/otp/commit/18943e753f7791312d89943851169e89acece8fc

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

https://github.com/erlang/otp/commit/a612e99fb5aaa934fe5a8591db0f083d7fa0b20a

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:

http://erlang.org/pipermail/erlang-questions/2012-August/068575.html

/Bjorn

-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB