I/O from binaries

Chris Pressey cpressey@REDACTED
Tue Nov 6 09:43:11 CET 2001


On Tue, 6 Nov 2001 08:23:14 +0100
"Fredrik Linder" <fredrik.linder@REDACTED> wrote:

> Just want to add som thoughts to this.
> 
> Maybe it is a bit "forbidden" to talk about OO here (I don't think it
> should
> be), but is not Chris' proposal a bit like inheritance in OO, the good
> parts
> of it?

I would say that inheritance and behaviours are two ways to express a
generalization/specialization pattern.  A subclass specializes its
superclass, and an implementation module specializes a behaviour module.

Whether there's a further similarity is questionable.  Behaviours are (to
me) a bit more like templates for Java-like interfaces, than they are like
object classes.  Erlang doesn't have any built-in "dispatching" strategy,
so any "inheriting" of methods, properties, etc has to be explicitly
coded.

> Yes, there are both strengths and weaknesess with inheritance. An
> example of
> its strength does Chris' give an sample of in his discussion, and an
> example
> of its weaknesses is huge class-tree structures (that are hard to
> maintain).

Actually, I *don't* think I would propose behaviours which themselves
implement behaviours, at this point.  In other words, in my mind there is
generally a simple, non-hierarchical, two-level relationship, between
behaviour and implementation.  I would strongly discourage (over)use of
hierarchical behaviours of behaviours.  If I must impose a hierarchy on
it, I would see all behaviours as implementing a single universal
meta-behaviour that might be described best as an imaginary Erlang module
like so:

  -module(meta_behaviour).
  -export([behaviour_info/1]).
  behaviour_info(callbacks) -> [{behaviour_info, 1}].

Thanks for the thoughts, and the chance to clarify, maybe :)

Chris



More information about the erlang-questions mailing list