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