More GUI (ravings?)

[Peter Caven]

Hello Vlad,

In my opinion, there has been some very deep thinking and a lot of work done
in this area by Kevin Sullivan, Ira Kalet and David Notkin.
My enlightenment occurred when I read their paper about the implementation
of the Prism system:

Mediators in a Radiation Treatment Planning Environment (1996)
http://citeseer.nj.nec.com/sullivan96mediators.html


Some additional papers are:

http://citeseer.nj.nec.com/sullivan94mediators.html
http://citeseer.nj.nec.com/sullivan93prism.html


-- Peter.


----- Original Message -----
From: "Vlad Dumitrescu (EAW)" <Vlad.Dumitrescu@REDACTED>
To: "Erlang-questions (E-mail)" <erlang-questions@REDACTED>
Sent: Monday, March 03, 2003 5:32 AM
Subject: More GUI (ravings?)


> 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 me.
>
> 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) ->
> widget: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 from
>
> Another way is to use for example an attribute
> -inherits([widget]).
> and then either:
>    * change error_handler:undefined_function to check any modules named in
'inherits' for the respective function before reporting an undef error
> or
>    * let the compiler generate the stubs above, but then only one "parent"
can be used.
>
> Yet another way would be writing behaviours on top of other behaviours,
and also let one process implement several behaviours.
>
> Or even modify the language to allow for generic functions (à la Lisp)
that can be extended from another module than the one they were originally
written in.
> ----
>
> I am reluctant to use the term "inherit" but I found none better. What is
needed is indeed a behavioural inheritance, which might not have anything to
do with objects and classes as we learned to love/hate them :-)
>
> I don't think I am completely out in the bush, but if I am, please let me
know. :-) I will have to give this more thought, but I feel some feedback
will be useful.
> regards,
> Vlad
>
>
>