|
From: Jim I. <ji...@ap...> - 2000-07-28 17:22:05
|
Also sprach Jeffrey Hobbs:
> ... Sure, Tcl is great as it is, but for a lot
> of people its only great when they have itcl, blt, tix, patches for better
> C++ compatibility, more data structures, etc etc. Fewer and fewer are
> truly satisfied with what the "core" provides.
This is just slightly off the point, but I don't understand this last couple
of sentences. It seems like you are implying that the fact that the core of
Tcl, by itself, is an incomplete solution for most complicated tasks is a
bad thing. Is that right?
I thought the aim was to get more stuff out of the core (making it thereby
even LESS satisfactory by itself) and then making the process of acquiring &
deploying extensions so easy that you would never hesitate to do so... That
is still our goal, right?
As for introducing backwards incompatibilities, I agree with Brent a bit
that we should not break Tcl compatibility unless there is some really
compelling need. I don't see any evils of the Tcl language that we are
likely to cure in a good way (as opposed to, for instance, introducing some
other comment syntax that breaks the current Tcl mold), that would require
backwards incompatilibilities at the syntax level. But in any case, this
should be approached with some caution.
It would, on the other hand, be nice to rearrange some of the commands to be
a little more coherent. It would be good to gather all the list commands
together, and maybe even make the open & socket commands return objects, so
we can get rid of this horrible mess of fconfigure, fblocked, eof... But I
don't think that any of the subsystems are so badly designed right now that
we couldn't provide wrappers for the old syntax...
As for C level changes, this should really be a community vote type thing.
We need to balance the desire to clean up & make more powerful the new
internals that were introduced in 8.0 & friends, with the need to carry
along most of the major extensions. So before we start wholesale changes
like this, we should have a discussion of the merits, and make sure we have
easy transition paths for all the many bits of C code out there...
Jim
--
Jim Ingham ji...@ap...
Apple Computer
--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe: email tcl...@aj... with the
word UNSUBSCRIBE as the subject.
|