More GUI (ravings?)
Wed Mar 5 01:58:24 CET 2003
On Mon, 3 Mar 2003 11:32:57 +0100
"Vlad Dumitrescu (EAW)" <> wrote:
> Hi all,
> Since I am working on ex11, I am also trying to see what might come
> ahead and try to plan for a possible widget toolkit, implemented in
> Erlang. As I said once before, I can't see any way to do it in a
> different way that it is done in most other languages, that is OO or the
> like. Please if there is anyone that has a link to a GUI framework that
> isn't OO (but not too far from Erlang's philosophy either), send it to
The structural parts of GUIs tend to be modelled as OO objects, because,
well, it fits. But there are other aspects that don't get as much press -
GUIs almost universally work in terms of events when it comes to the
dynamic aspects, and rules when it comes to layout - but these generally
get downplayed, because the structure is more 'obvious' to the
visually-inclined end user I guess.
> The "missing feature" that would be needed has already been discussed
> here in many ways: building a hierarchy of behaviours. Or with another
> word, implementing subclassing. A generic window has behaviour that an
> input widget will "inherit" and that one can further be refined to
> become a "password input" widget.
> The question is how to delegate the "inherited" behaviour to the right
> implementation module?
> One way is to just write lots of funs similar to
> set_visible(Widget) ->
> But this seems very heavy on the typing fingers and not extendible.
> Maybe some macros could help, but it would look like a C++ framework
> Another way is to use for example an attribute
> and then either:
> * change error_handler:undefined_function to check any modules named
> in 'inherits' for the respective function before reporting an undef
While this would work great, for better or worse, it's not very Erlang-y.
I think the Erlang-y solution would be
loop(Parent, State) ->
Parent ! AnyMessageIDontUnderstand,
But honestly, I like trapping undefined_function better - this
pass-the-message-through-back-to-the-parent-process way will
result in a *lot* of processes, and even though that's OK here, it still
feels wrong - because the processes seem *superfluous*. One process per
real-world activity - the textbox underlying a passwordbox isn't *really*
a discrete real-world activity, is it? It doesn't seem to have an
existence independent of the passwordbox, to me.
More information about the erlang-questions