Tcl/TK is indeed dying
in [TCL]
|
Prev: www.prevayler.org anyone do an in ram data base with transactionlog in tcl?
Next: accessing GUI with TWAPI (was: Accessing GUI of CAD through Tcl/Tk)
From: tom.rmadilo on 22 Dec 2009 16:25 On Dec 22, 1:51 am, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > On 21 Dec, 17:17, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > > > In my test htclient code, about a third to one-half of the code is due > > to the inability to push back one char (\r). One solution would be to > > use a stack, another would be to add Tcl_Ungets to the script level. > > As noted, a stacked transformation might be the way to do it. Requires > Tcl 8.6 though (we didn't get around to implementing them in 8.5; the > C-level API is there, but the scripted was later). Curious that we > have such different experiences of what parts of an API are useful. > Not that I'm calling you wrong though; there's a known fact that > everyone needs a different subset of the basic features of a piece of > software. Indeed, the first time I can recall seeing it enunciated > clearly was in relation to MS Word's feature-itis. I'm perfectly happy to work within the confines of the language. The only reason I recognize the utility of "ungetc" is that I have used it in a lexer/parser, so I understand the benefits. Of course the fact is you can work around this easily. So what if it takes a little more work. I'm not too interested in using the absolute minimum amount of code or removing every additional copy of a code fragment. What is more important to me is that the fragments, even if reused, are recognized as a unit of execution. Maybe you could call it an inline procedure. Future maintainers will recognize the code block just as they recognize any other function call. It is more or less like unrolling a loop. It is really hard to define when code repetition is a good solution and when it is the result of pure accident or mistake. In other words, a child could create a Jackson Pollock by throwing paint on a canvas. But there was no process behind the child's creation. In some instances, there is method to the madness, in others, there is just madness or a total lack of understanding. The basic argument against goto is that it is hard to distinguish between method and madness. Since I consider source code to be a form of communication, goto is really just an ambiguous directive. Ambiguous language does not enhance communication. (Ambiguous just means that more context is required for interpretation.) |