[erlang-questions] multiple behaviours

[Tony Rogvall]

Hi!

I am compiling the canopen stack (git://github.com/tonyrog/canopen.git) and get the following warning:

../src/co_os_app.erl:37: Warning: conflicting behaviours - callback index_specification/2 required by both 'co_stream_app' and 'co_app' (line 36)

The question is:

I can realize the reason for the warning, but we want to share some (one in this case) 

of the callbacks in the different flavours of the behaviours. 

One simple interface, one advance interface and the possibility to implement both ....

In this case we could probably solve it by adding yet an other behaviour that does not

require you to use both, but merge the parts needed.

/Tony

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"

[Samuel]

> I am compiling the canopen stack (git://github.com/tonyrog/canopen.git) and
> get the following warning:
>
> ../src/co_os_app.erl:37: Warning: conflicting behaviours - callback
> index_specification/2 required by both 'co_stream_app' and 'co_app' (line
> 36)
>
> The question is:

And no question followed ;)

Ideally you could suppress the warning as you really intend to share
the same function for both behaviours, but as far as I know there is
not such an option in the compiler, so you either suppress all
warnings for that module or learn to live with this one.

Or, as you also suggest, write a new behaviour combining those two. If
this situation is not common in your design I would suggest this
solution as prevents you from going against what I think is the
intended use of behaviours. I guess the original idea was to have at
most a behaviour per module, but more authoritative voices may have a
word about this.

If you was planning to have many of those behaviour combinations, the
second option seems bad idea, as the result could be messy.

Best
--
Samuel
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Tony Rogvall]

On 6 jun 2012, at 14:13, Samuel wrote:

>> I am compiling the canopen stack (git://github.com/tonyrog/canopen.git) and
>> get the following warning:
>>
>> ../src/co_os_app.erl:37: Warning: conflicting behaviours - callback
>> index_specification/2 required by both 'co_stream_app' and 'co_app' (line
>> 36)
>>
>> The question is:
>
> And no question followed ;)
>
> Ideally you could suppress the warning as you really intend to share
> the same function for both behaviours, but as far as I know there is
> not such an option in the compiler, so you either suppress all
> warnings for that module or learn to live with this one.
>

Yupp.

> Or, as you also suggest, write a new behaviour combining those two. If
> this situation is not common in your design I would suggest this
> solution as prevents you from going against what I think is the
> intended use of behaviours. I guess the original idea was to have at
> most a behaviour per module, but more authoritative voices may have a
> word about this.
>

Any takers on this topic (meaning people involved in the design of course)

> If you was planning to have many of those behaviour combinations, the
> second option seems bad idea, as the result could be messy.
>

Thanks.
Wow, someone answered a question sent 7 days ago :-)

/Tony

[Ulf Wiger]

On 6 Jun 2012, at 15:33, Tony Rogvall wrote:

>> Or, as you also suggest, write a new behaviour combining those two. If
>> this situation is not common in your design I would suggest this
>> solution as prevents you from going against what I think is the
>> intended use of behaviours. I guess the original idea was to have at
>> most a behaviour per module, but more authoritative voices may have a
>> word about this.
>>
> Any takers on this topic (meaning people involved in the design of course)

This has been debated.

Since my part-time job is to fill the list with old gossip about
the time before discussions moved to the web, this is the story
of behaviors (at least as I recall it). For my current opinion,
skip to the last paragraph.

The first behavior-style components were actually built in
BOS, a middleware layer designed for, and partly by, the
first real commercial erlang-based product: Mobility Server.

BOS was the predecessor of OTP. When designing OTP,
the concept of behaviors was evangelized by Joe Armstrong
as a more generalized version of the support libraries in BOS.

Back in those days, it wasn't easy at all to define your own
behavior; the linter had hard-coded knowledge of the ones in
OTP, and would not help with any 'fake' behaviors.

After having read a nice thesis (can't recall where to find it)
about behaviors, which also described how to hack your
own behaviors - painful, but rewarding if you could prevail.

I wrote a prototype that introduced the behaviour_info/1
callback. It was accepted by OTP, with typos and all
(I had used the American spelling, and it took a while
before someone pointed this out; by this time, the
easiest remedy was to accept that the erlang linter
had become bi-lingual).

There were discussions now and then about whether it
was ok to mix behaviors in a single module. The OTP
stance was that it was frowned upon, but their case was
weakened by the fact that this is done in a number of
places in OTP (e.g. kernel.erl). Nowadays, the linter
accepts multiple behaviors, as long as they don't lay
claim to the same callbacks (checking Fun/Arity only).

With the new -callback() types, it should be possible to
accept overlapping callbacks, as long as their type
signatures are compatible (preferrably the same).

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com

[Samuel]

> Wow, someone answered a question sent 7 days ago :-)

Actually, it was motivated by Joe's mail about questions lingering
unanswered in the list, I just scan back a little to find one that I
could surface again :)

Regards
--
Samuel