-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Donal" == Donal K Fellows <···············@cs.man.ac.uk> writes:
Donal> What exactly do you mean by "subclassing"? How can you be sure
Donal> that you need a C extension to do it with Tcl/Tk? I have made
Donal> Tcl/Tk-only labelled frames, comboboxes and progress meters
Donal> quite easily, so it is entirely possible that you are simply
Donal> mistaken in your assertion.
Let me put it this way: you can define new Tcl functions so
my_button .foo -text "Bar" -command "puts foo"
works. However, you have to do an incredible amount of work to get
this to work, because you have to define a function `.foo' with
half-a-hundred cases for everything you *might* want to do. Also, you
run into name collisions; suppose .foo is some sort of wrapper about
.foo__WHEE_IM_A_MANGLED_NAME. How do you differentiate names? How do
you allow
my_frame .foo ...
my_button .foo.bar ...
to work?
Compare this to
foo = My_Frame(root, ...);
bar = My_Button(foo, ...);
in Python.
>> - lists where accessing anything is an O(n) operation
Donal> What version are you talking about? This (a long-standing
Donal> complaint of many Tcl entheusiasts) is no longer true in Tcl8.
Never used Tcl8, don't plan to. The best thing about Tcl8 is that Tk
is finally moving away from its Tcl foundation, so I get all the
benefits of Tk in a real language. Also, which implementation did
Ousterhout choose to support? lindex and lappend have quite different
penalties, which is why STL supports vector<> and list<>.
Does Tcl8 do 8-bit strings yet?
>> - numbers that autoconvert when you don't want them to (on east
>> coast area codes, for example)
Donal> I believe this (another moan of great age) is fixed too.
Again, don't know about this.
However, these two changes alone implies some really major reworking
of the compiler, like adding a type system. Does this mean that Tcl
is then shedding the `everything is a string' attribute that
Ousterhout considered so wonderful?
>> - non-extensible mathematical expressions (think expr here)
Donal> Fair enough, though I'd add that putting in your own stuff
Donal> (which does admittedly have a different syntax) is still not
Donal> hard.
True. However, it is very different syntax.
Case in point: I was considering Tcl for a built-in language for a
system I was going to rewrite. I rejected it when I discovered that
- Tcl doesn't have a rand() function in expr.
- I couldn't put one in.
- The alternative syntax would've been hairy.
I was trying to rewrite a MUD derivative, BTW, and a good random
number generator was essential; it would be used certainly much more
than sin(), hypot() or log10() in this context.
>> - call by name - dynamic scoping
Donal> These two are construable as a feature (though I would like the
Donal> other kind of semantics AS WELL... :^)
I can't really consider them that. It causes real confusion, although
it's better than the situation in LISP 1.5...
>> and other assorted nastiness. Even Perl is a breath of fresh air
>> compared to this.
Donal> For some things.
I'm talking about syntax, here. Remember
while {1} { # <- error! # is a _function_
}
Unless Ousterhout has changed Tcl so much that it isn't just a
glorified macro processor, the cost/benefit equation hasn't changed.
And if he *has*, then the conversion isn't worth it to me.
Donal> I suppose it all depends on your definition of trivial, but
Donal> there are commercial applications out there written in Tcl/Tk
Donal> with over a million lines of code. I do admit that systems of
Donal> that size (whatever written it) boggle my mind a bit
Donal> though... :^)
Let me qualify that statement, then. I'm not saying that people don't
do it; my mail reader is somewhere around 35k lines of Tcl/Tk. I'm
just saying that *I* wouldn't.
- - --
Graham Hughes http://A-abe.resnet.ucsb.edu/~graham/ MIME & PGP mail OK.
const int PGP_fingerprint = "E9 B7 5F A0 F8 88 9E 1E 7C 62 D9 88 E1 03 29 5B";
#include <stddisclaim.h>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBM04A3CqNPSINiVE5AQH4TAP/QOmSLxuoWThBgrIN9lSdCcH/YJ1AIaqF
knr4F3MALI/yopVHwebHEENS8GW77L7MaZNUdAhO3niNnHzfE7LsL564bdP0AKBP
urvAft5IIeZ36XhPt7IXZO8rTRq/qetHQsa9VXVHFc71kyljj6AXHXfe6I2VIg54
wkeSkFH38MM=
=ARhJ
-----END PGP SIGNATURE-----