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

[Eric Newhuis]

Is there a good write-up on parameterized module alternatives anywhere?

- always include an .hrl  and pass a record instance as arg 1 ?

On Oct 8, 2012, at 7:24 AM, Gordon Guthrie wrote:

> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions