Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!well!nagle From: nagle@well.UUCP (John Nagle) Newsgroups: comp.lang.c++ Subject: Re: Combining event driven and object orient programming Message-ID: <14004@well.UUCP> Date: 8 Oct 89 19:07:57 GMT References: <13928@well.UUCP> <13929@well.UUCP> Reply-To: nagle@well.UUCP (John Nagle) Distribution: all Organization: Whole Earth 'Lectronic Link, Sausalito, CA Lines: 43 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >In article <13929@well.UUCP> nagle@well.UUCP (John Nagle) writes: >Isn't one possibility to not lose the context by calling the event loop >instead of returning to it? This may require a little rearranging of callback >routines because the new context (the sub-event loop) shouldn't handle all the >normal callbacks, just those that make sense in the new context. If the event >loop (or event handler) is treated like an object (with static memory areas), >there should be no problem in constructing a new event loop. Right? That approach results in a mode. If you want a modeless event processing model, as the Apple Human Interface Guidelines suggest, such an approach is inappropriate. You should be able to do anything at any time unless there is some pressing reason to prohibit inherently incompatible actions. If you like a calling-type model, something like Common LISP closures might be helpful, as an alternative to tasking. >The question I have hear (sic) is not so much "buying" into the cheap multitasking >(or even sub-event processing), but rather the manner of getting out of it >when the subtask is done. Is there a return value from this other task or >does the task signal its parent with a new event? Assume that the reason for >invoking the other task was to get information from another "process" (user, >database, whatever) and construct an object from that information that the >current task can work with. What should be the method of giving this object >back to the parent task? You fork off a task when there's no need to wait for the result. Suppose the application can open various kinds of documents, but opening may be time-consuming. Having initiated opening of a document, the user should be free to make further selections and open more documents while the first document opens. It's OK to call a subroutine that takes time, but not from the main event loop. The idea is not to take control away from the user. >One naive question, though. Define "smart" dispatcher? One which supports preemption, priorities, time-slicing, and wait/send (or P/V) type operations. A dumb dispatcher can only transfer control at predefined points. John Nagle