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

[Gordon Guthrie]

We use Mochiweb which makes extensive use of them.

So is the general advice that everybody should migrate away from Mochiweb?

Gordon

On 8 October 2012 13:15, Björn Gustavsson <bgustavsson@REDACTED> wrote:
> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions