I/O from binaries
Wed Nov 7 06:48:14 CET 2001
On Tue, 06 Nov 2001 09:49:11 +0100
"Vlad Dumitrescu" <vladdu@REDACTED> wrote:
> I am thinking in the same paths as Chris, so I think it's a good idea
> Yes, I think it looks like OO, but at the same time it isn't. It is more
> like the COM framework, where there are interfaces for objects to
> The main difference compared to inheritance is that the structure is
> avoiding the above named weakness. Of course, one could build a deep
> hierarchy, but the natural way is to use a flat one.
There might be rare circumstances when a hierarchy might be called for,
but I think 'rare' is the important word in that statement.
I've put my thoughts on OO on Bluetail's Erlang Wikie (but it doesn't seem
to get a lot of traffic, and I don't know what it's future holds) so I'll
summarize them here. I think inheritance is one of the more overrated
features of OO, and message-passing is one of the more underrated. People
tend to overestimate the 'reusability' gain from inheritance, and waste
time trying to come up with the 'correct' hierarchy. In my experience, OO
successes seem to be more attributable to encapsulation: making sure that
objects talk to each other through their interfaces. And Erlang has
encapsulation and message-passing in spades, of course!
Inheritance has its place, but I think I would limit its use to modules,
not behaviours. It would be pretty easy to cook up a parse transform to
make inheritance dispatching implicit... hmm... in fact I might experiment
with this in the near future :)
> Whether this interface definition should use "behaviour" or another name
> avoid misunderstandings) is a question of taste, but I use it in my
> and it should be nice to have a compile-time check enabled.
I can't really think of a better name than "behaviour", and I don't find
it that confusing. It's a behaviour with no callback functionality which
only defines an interface. Maybe a "null behaviour" or an "interface
More information about the erlang-questions