Hi Heinrich, Hi Ertugrul
thanks for all your comments so far. In last e-mail, you wrote:
Heinrich Apfelmus <[email protected]> wrote:
In the case of HGamer3D, the sink combinator would replace the need to
declare a final "wire which runs all the wires at each step". It
feels a bit weird to me to have wires like guiSetPropW that perform
side effects, i.e. where it makes a different whether you observe
their results or not. That's a complexity where I feel that something
"has been swept under the rug".
In particular imperative wires like guiSetPropW (or anything for which
*set* is a sensible name) are simply wrong. A widget, e.g. a button,
should look like this:
type MyWire = WireM (Reader MyConfig)
type MyEvent a = MyWire a a
button :: MyEvent Button
=>
A short explanation on the guiSetPropW wire:
The guiSetPropW can be considered as being part of the GUI binding actually. It
is
in the public Api to overcome the limitation of not having all properties as
single wires coded.
Anyhow, if you want to act on something in the GUI (for example make a window
visible or not)
you will probably need something with a side effect. That is, where
the guiSetPropW is used in the examples. But it is a little bit low level, the
higher level wires look more nicer:
for example, the button wire creation acutally looks like that:
buttonW:: GUIElement -> GameWire a a
with the button wire having the type of: GameWire a a
It is a pure event wire, which gets fired, when the button is pressed.
the "label" wire creation
staticTextW :: GUIElement -> GameWire String String
with the labe wire having the type of: GameWire String String
the "editbox" wire creation:
editBoxW :: GUIElement -> (GameWire a String, GameWire String String)
creates two wires, one for getting notified on changes of the element:
type: GameWire a String
and one for setting a new value to the string:
type: GameWire String String
Here, I would be interested in your view. Of course you can make one wire out
of it, but this has different
consequences:
- how to check for a change in the widget, if the wire is not executed, because
no input value occur?
- usually you need the output of the wire in different places of your final
network where the input wire is needed, if you have only one wire this might be
cumbersome, to code in combining the final network
- and: yes, there has been also something swept under the rug here, because
since both wires refer to the same GUI element, there is the same GUI element
used inside, which is a reference. Actually this is somthing more OO/Scala like
then Haskell but it works fine for me so far, since it does overcome the
limitations of the points above.
BR
Peter
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
