On Wed, 19 Mar 2003 14:46:47 +0000
Axel Simon
Gtk uses a very similar approach in that each event can have several callbacks registered and you can remove each callback individually. So I think my proposal serves this 1:n correspondance
I can think of many other ways to solve the problem. And, besides, I can see many other ways to initialize, and access fields of, widgets and things that have properties, in general. Now I play the role you played against me last week :) : if all the toolkits allow it, can we have function wich take no initializers, and provide get and set functions for attributes? Other approaches are implementable on top of this really weird interface. This is an attempt to lower the priority of the problem of handling local state of the widgets. When we have a strong basis well built, and working flawlessly on various platforms, we can create teams to standardize the mid-level syntax. Now, I know that I was saying the opposite last week; you really convinced me that it's best to solve low-level issues before mid-level ones, and I wish people on the list to have time to elaborate what the various alternatives can be. Besides, I see a very clear distinction between what's low-level and what's mid-level: - low level is everything that needs FFI and/or writing to handles to be implemented. - mid level is everything that can be implemented in haskell, over the low level ground. So, I ask to everybody: would it be right to provide a working low-level interface, in the IO monad, even if it sucks completely, call it "the CGA core", and ONLY THEN think about issues as initialization syntax and a nice way to handle local state? Note that this does not mean that we'll claim that our work is finished, when we have the core. Instead, we'll really focus on the mid-level, and produce a good one, before declaring the CGA as a standard; this is necessary IMHO. Let's vote for this, here are the two alternatives 1. to have at least a simple syntax wich is not like an assembly language is good, and comfortable even when writing the low-level stuff; so it's better to design some standard mid-level interface right now 2. by designing a weird interface in the IO monad, similar to the ones we find in traditional imperative languages, we will produce the core much faster; it will be minimal and open to other implementation; also, people will have more time to think to nice syntaxen and the state handling issues; so it's better not to do any mid-level stuff right now. I obviously vote for 2, but I prefer to count much less than other, more experienced people on this list. Vincenzo