Newbie switching from TCL

[Robin Becker]

In article <8o1li30e3r at news2.newsguy.com>, Alex Martelli
<alex at magenta.com> writes
...
>Who made that assertion which you were responding to?  It was
>
touché
>Tcl's architects may have chosen that architecture for portability
>reasons.  There may be a few ways to do general eventing on
>System V, a couple more to do it on BSD, a few more to do it
>in VMS, yet others for Win32, MacOS, BeOS, etc, etc -- but if
>you want to use a single architecture and do a decent job of
>covering them all, you're probably left with auxiliary thread[s]
>as maybe the only choice that stands a chance.

"the design is indeed baroquely rich and complicated," see your pp post
'rich' usually  has good connotations, but perhaps I misunderstood the
remarks related to  RegisterBindStatusCallback, CreateFile, ReadFileEx, 
SendProgress, SendComplete, Connect, ConnectionRequest, ... etc etc

As for the so called event call backs, as I stated before, many of these
are in fact initiated by a separate thread of control (often in the OS)
usually on the same processor. There's nothing magic about them and
aside from the explosion of verbiage many could be described by quite
simple wrappers around the actual worker. So a file read has to be made
more (not less complex) in order to do the byte counting etc to provide
progress etc call backs. Agreed the very lowest level operations them
selves might make this easy or hard, but there's nothing magical about
the implementation of such call backs.

There are in fact real events in physical hardware, traps interrupts or
whatever you want to call them, but I think these have little to do with
VB in the normal course of things.
-- 
Robin Becker