Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Kevin W. <kw...@co...>]

Hello Michiel,

Thank you for your feedback. I am certainly happy to hear your thoughts 
about further improving Tk-Cocoa, but I did need to touch on a couple of 
things immediately:

> 1) In Tk, the design of the event loop (in particular, processing events in the event loop rather than in the callbacks);

Tk is building on Tcl's event loop, which is a core feature of the language.

> 2) In Tcl, the use of a separate thread to monitor file descriptor events.

Tcl supports but does not require threading, and in fact threading is 
often unnecessary because of the event loop.

Re-engineering either of these foundational parts of Tcl would, as I 
understand it, go far beyond adjusting a platform-specific 
implementation of the current API (which is what I have been working 
on). While I'm not a member of the TCT (Tcl's core governing committee) 
and can't speak for them, I find it hard to imagine that there would be 
much support for changing the event loop (this would require a large 
effort across every platform) or for adding threading as a required 
component.

Tcl's inventor, John Osterhout, argued that threads are a bad idea in 
most instances because of their complexity, and advocated event loops:

http://www.cs.utah.edu/~regehr/research/ouster.pdf

I realize that threads are very commonly used today, and are a standard 
part of the Cocoa programmer's toolkit, but some increasingly prominent 
software projects (cf. node.js)  are discovering what Tcl has known for 
two decades: event loops are powerful. I have only done a little 
threaded programming myself, and have generally avoided it because Tcl's 
event loop makes it unnecessary for my needs.

Just a few ideas to consider. Looking forward to your thoughts.

Thanks,
Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com