Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!ATHENA.MIT.EDU!swick
From: swick@ATHENA.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: Re: A Call for Callforwards...
Message-ID: <8906301522.AA03127@LYRE.MIT.EDU>
Date: 30 Jun 89 15:22:15 GMT
References: <8906292347.AA04479@bu-cs.BU.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: DEC/MIT Project Athena
Lines: 21


     Date: Thu, 29 Jun 89 19:47:42 EDT
     From: bzs@bu-cs.bu.edu (Barry Shein)

     What about the semantics of multiple callbacks supported by
     CallCallbacks, does this gibe with passing data back? How is it
     coordinated so the call_data isn't stomped on multiple times (ok, the
     programmer should just be careful

Ah, the canonical flexibility vs. potential for error trade-off.
Paul's example illustrates well why you might not wish to enforce
single-entry callback lists universally, but I certainly understand
the desire to have the library (dynamically) verify any constraints
rather than the application or debugger.

If we were starting over, the most useful improvement over Paul's
suggestion (of passing a flag around with the data) I can think of
would be to use the function return value from the callback to
stop processing the remainder of the list immediately, thereby
avoiding even the procedure call overhead.  But then we'd have
programmers making errors the other way :-)