Brian Hulley wrote: > Brian Hulley wrote: >> apfelmus wrote: >>> Brian Hulley schrieb: >>>> main = do >>>> buffer <- createBuffer >>>> edit1 <- createEdit buffer >>>> edit2 <- createEdit buffer >>>> splitter <- createSplitter (wrapWidget edit1) (wrapWidget >>>> edit2) >>>> runMessageLoopWith splitter >>>> >>>> ... Thus the ability to abstract mutable state gives to my mind by >>>> far the best solution. >>> >>> I'm not sure whether mutable state is the real goodie here. I think >>> it's the ability to indpendently access parts of a compound state. >>> http://www.st.cs.ru.nl/papers/2005/eves2005-FFormsIFL04.pdf >> >> This is indeed a real key to the problem. > Of course this is only one aspect of the problem... > > Thinking about this a bit more, and just so this thought is recorded for > posterity (!) and for the benefit of anyone now or in a few hundred > years time, trying to solve "Fermat's last GUI", the object oriented > solution allows the buffer object to do anything it wants, so that it > could negotiate a network connection and implement the interface based > on a shared network buffer for example, without needing any changes to > the client code above, so a functional gui would need to have the same > flexibility to compete with the OO solution.
I'd be careful. Introducing a network connection into the equation makes the object (its methods) susceptible to a whole new bunch of failure modes; think indefinite delays, connection loss, network buffer overflow, etc etc. It may be a mistake to abstract all that away; in fact I am convinced that the old Unix habit of sweeping all these failure modes and potentially long delays under a big carpet named 'file abstraction' was a bad idea to begin with. The ages old and still not solved problems with web browsers hanging indefinitely (w/o allowing any GUI interaction) while name resolution waits for completion is only the most prominent example. Cheers Ben _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
