Behaviours (was: I/O from binaries)

[Vlad Dumitrescu]

Me again...

[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 
feedback.

See you later,
Vlad

_________________________________________________________________
Hämta MSN Explorer kostnadsfritt på http://explorer.msn.se