Behaviours (was: I/O from binaries)
Wed Nov 7 07:16:37 CET 2001
[If you want to skip my ravings written at 6am, look down for a ***]
This discussion is interesting, as it unfolds some different ways of
thinking about program & system structure. The hardcore Erlangers seem to
disclose OO straight away, while newcomers (like me) do not. It may be a
normal phase in the evolution of an Erlanger, or it may be not... To me OO
isn't anbout object or inheritance, but about how to grasp the complexity of
a system and make it easy to handle.
I would like to not use the name "OO". Objects are but one way to think
about it. The same things can be accomplished with modules and processes and
interfaces - does that sound familiar? :-)
One thing that I am working on right now, and I hope to have something to
show within two weeks when my parenthood leave ends, is something I am very
curious about how it will work. I see it as a very nice way of training in
Erlang, testing it's capabilities and maybe stretching some limits, while
applying the "module, process, interface" thinking.
It is an older idea, a windowing system all in Erlang, with a framework for
building GUIs. Each window (including widgets) is a process and there is a
top-level one that communicates with the world (input and drawing).
The design is layered and one could say there is some kind of "inheritance".
Let me see if I can explain nicely without using "forbidden" terms...
* A window process is a server (that may be using gen_server or not) that is
generic: there are a number of callbacks to be implemented later.
* Each widget's functionality is defined in a separate module, implementing
those callbacks, and at the same time defining some new generic ones.
* In an application, these last callbacks are defined to implement the
specific application functionality.
* There is also another set of parallel callbacks, that define the
look-and-feel of the widget(s). These might be defined for each widget, or
globally for each look&feel.
It isn't as strange as it looks like. The intention is to separate different
categories of functionality, "general widget" from "look & feel" from
"application-defined". Each can be changed separately, there are only
loosely coupled through interfaces (behaviours).
It is kind of a "behaviours on behaviours" as Chris said, but I don't really
see some other scheme that will allow this kind of flexibility. And it
doesn't seem so complicated that will obfuscate the whole system... Anyway,
regular users will only see one behavioural level (the application one). The
other is visible only when writing new widgets.
I see this project as an interesting research, it might not be fast enough
to work in real life. On the other hand, Java is not fast either, while this
is something that Erlang is supposed to be best at: many small processes
doing little work and not communicating a lot.
Anyway, when I will have something to show, I will post it here. If anyone
had the strength to read all of this and has comments, I won't mind to get
See you later,
Hämta MSN Explorer kostnadsfritt på http://explorer.msn.se
More information about the erlang-questions