Squeak is a great programming tool that
lots of coders will never get a chance to truly exercise (yet?). One thing
about getting into any software project is also learning about the community
that keeps it alive. Usually this means finding websites with information
on it or keeping up with mailing lists. However, the
Squeak
Development Mailing List gets a truly heavy amount of email per day
(Easily 40+ mails on a not so fast day). This is very hard to keep up with
but it also shows that the Squeak project overall is very lively.
Enter Squeak Weekly an
effort by one person to try to take the best of what’s happening in the
Squeak community every week and summarize it. It also has interviews or
Q&A sessions with many primary Squeak people in the community which is a great
way to understand what is happening within the community.
This week’s interview was with Andreas Raab and I found some interesting
stuff out on Tweak:
Another key idea in Tweak is that of asynchronous event handling. Unfortunately
I can’t say I invented that (though at the time where I came up with the idea I
wasn’t aware of anybody else doing it) but it turns out that this is what is
now typically referred to as “event-loop concurrency”. The idea here is that
all responses to events are asynchronous messages, e.g., are executed some time
*after* the event has been signaled. The reason this is important is that by
using asynchronous events you do not expose internally inconsistent state to a
listener.
When you use synchronous events (callbacks) you end up with the
problem that the listener (inadvertently or not) may request temporarily
inconsistent state or otherwise violates the invariants of the computation
(like raising an exception). A good (or rather bad) example is the system
notification mechanism in Squeak – it allows listeners to interfere *during*
the compilation process with unclear results what might happen if there is any
problem. In Tweak this simply cannot happen
