[prev] [thread] [next] [lurker] [Date index for 2007/01/29]
On 29 Jan 2007, at 15:21, Peter da Silva wrote: > On Jan 29, 2007, at 7:00 AM, Andy Armstrong wrote: >> I guess you don't like signals / slots or callbacks in general >> either then? > > They're all useful tools. They should all be used with extreme > care. Concurrency and asynchrony have to be dealt with somehow, and > the tools that have developed to deal with them carry the > hatefulness of concurrency around with them. Applying these tools > to normal errors (e.g. file not found) is hateful. Signals / slots != signals. They're not async. http://doc.trolltech.com/3.3/signalsandslots.html > Exceptions should be reserved for errors that aren't normally > recovered from. It should require the equivalent of "#pragma > FIXME_THIS_IS_EVIL_CODE" to do anything at the end of an exception > handler other than throwing the same exception again. So how are you proposing to propagate recoverable errors? Guard every function call with a conditional? > Signals should be reserved for infrequent asynchronous events. Yes, > SIGFPE, I'm looking at you. Signals / slots != signals :) > Callbacks should be reserved for asynchronous events, unless you're > working in a fully reflective language where they can be used as > generators. If you have to define a procedure, signal handler, or > callback method for normal return from synchronous code, something > is wrong or hateful. > >> Or closures? > > I wouldn't class closures in with signals and callbacks, but I've > mostly dealt with closures where they're basically generators. It > wouldn't surprise me to learn that there's hatefulness lurking there. Your world scares me. >> They're all to do with the flow of control bouncing around in >> ways that weren't explicitly designed into the code that does the >> transfer of control. > > The same is true of "return". Yup, we should get rid of that too. -- Andy Armstrong, hexten.netThere's stuff above here
Generated at 23:01 on 06 Feb 2007 by mariachi 0.52