More GUI (ravings?)

[Eric Merritt]

Vlad,

 I kind of think that you are being misguided by the
OO world. Don't get me wrong I like OO and don't think
it is a bad thing, but its not the only way to do
things. Inheritence is not the only way to handle
sub-windowing behavior either, I am pretty sure.

 Unfortunatly, I need to think about it before I can
offer suggestions, but I would say try to think in
native erlang datastructures and processes. They are a
good solution and they should work for this just like
they work for so much else. Don't try to reinvent OO
in Erlang. 

 I will give it some thought and try to offer some
suggestions soon.

--- "Vlad Dumitrescu (EAW)"
<Vlad.Dumitrescu@REDACTED> 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 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
> 
> 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/