UPDATE: Tcl/Tk release schedule

1 view
Skip to first unread message

Jeffrey Hobbs

unread,
Apr 10, 2000, 3:00:00 AM4/10/00
to
Several questions have come up about what the release schedule for
Tcl/Tk is in the coming months.

8.3.1 will be released on April 20th, with as many fixes in there as
we can verify are correct and patch in. If you have an interest in
a particular bug, please check the Tcl/Tk bug list
http://dev.scriptics.com/ticket/
to check on status and champion a bug that may need fixing still
(remember, patches are much more useful to us than simple reaffirmation
of a bug - but cases of single malt whisky and bars of gold conferred
upon members of the core group encourage late night hacking sessions).

8.3.1 is a patch release, which means no new commands or other such
outward changes. Primarily it focuses on bug fixes and optimizations.
So far 52 bugs in the db have been marked Fixed for 8.3.1 specifically.
This does not includes dups of fixed bugs, or bugs closed because they
aren't relevant to the core, and also doesn't include all bugs fixed
(I still get bugs in my inbox and find things on my own that get fixed
without making it into the bug db). There are several other partially
fixed (multi-part) bugs for 8.3.1, as well as requested internal API
changes. Basically it's a cleanup release that's getting fairly clean.

Certain fixes that came with patches are waiting for the 8.4 alpha
releases because they make changes that could have an adverse affect
for some users. This includes certain localization patches and the
XIM fixes.

8.3.1 is in a good state, so we will start working on 8.4 immediately
following 8.3.1's release. There may be an 8.3.2 sometime during the
summer (always leave the possibilities open), but this is not
currently planned. 8.4a1 (first alpha) should see release in late May
or early June.

So what's 8.4 about?

8.4 will see an increase in the distribution (not core) size of Tcl
and Tk, with new work also being done on Tk. Tk 8.4 will definitely
include some sort of megawidget system standard (as yet undetermined),
as well as new core widgets (spinbox, notebook, tree?) and hopefully
drag and drop support (if the community can solve the multi-platform
issues related to it). Tcl will include the new listx command, and
we will be looking at extending the number of truly byte-compiled
commands.

So what about the distribution is changing? It's time for the core
to truly expand its horizons, as well as embrace popular extensions
that users have been using as extensions (and going through the
pain of dl'ing and installing separately) for years. At first we
thought some sort of original net-based distribution system (and
'package acquire') would be a novel way to fix the problem. However,
the overwhelming opinion from users at Tcl/2K in February was that
they wanted it in a standard distribution ('package acquire' being
sensitive to system binary availability and net access).

The targeted extensions are the usual suspects: [incr Tcl], TclX,
BLT, expect, tcllib, and common requests like thread and more widgets.
It's uncertain what will actually end up in 8.4, as several of the
above extensions have parts that aren't designed for such a setup.

The core group is looking to achieve a distribution that still has
just the main installed executables of tclsh and wish, but with as
much functionality as manageably possible immediately available
via 'package require Extension'. However, TclX for example perturbs
the tcl_prompt behavior, and also has a TkX which I believe adds
no extra functionality anymore. Anyway, there are definitely issues
that need to be worked out, but that's the general plan for now.

8.4 will have regular milestone releases every couple of months or
so. Sometime near the end of the year is a likely final beta or
final release timeframe.

--
Jeffrey Hobbs The Tcl Guy
jeffrey.hobbs at scriptics.com Scriptics Corp.

Mark Harrison

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> The targeted extensions are the usual suspects: [incr Tcl], TclX,
> BLT, expect, tcllib, and common requests like thread and more widgets.

How about including itcl, and coding tcllib as itcl components?
I'm following up with a message regarding my experience with
the current tcllib implementation... so far, it's only been
so-so.

Basic summary:

- the items in the library are useful and good.
- the interfaces to the components vary.
- the implementation of abstract data types are
really hacky (in the bad sense).
- the performance on some of the data structures
promises to be not very good.

--
Mark Harrison ma...@usai.asiainfo.com
AsiaInfo Computer Networks http://www.markharrison.net
Beijing / Santa Clara http://usai.asiainfo.com:8080

Jeffrey Hobbs

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to Mark Harrison
Mark Harrison wrote:
>
> Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> > The targeted extensions are the usual suspects: [incr Tcl], TclX,
> > BLT, expect, tcllib, and common requests like thread and more widgets.
>
> How about including itcl, and coding tcllib as itcl components?
> I'm following up with a message regarding my experience with
> the current tcllib implementation... so far, it's only been
> so-so.
>
> Basic summary:
>
> - the items in the library are useful and good.
> - the interfaces to the components vary.
> - the implementation of abstract data types are
> really hacky (in the bad sense).
> - the performance on some of the data structures
> promises to be not very good.

You'll always get a bit of variance when multiple people work
on a common project, no matter how far you go with coding
standards. We don't want to squelch progress though by rejecting
stuff just because it doesn't "fit in". However, you're
guaranteeing it will be slower if you base it on itcl, so I'm
not sure that brings any more than a bit of class structure.

Those data structures which would most need speed improvements
(like the tree) are most likely to find themselves move to C
at some point.

Mark Harrison

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:

> Mark Harrison wrote:
>> Basic summary:
>>
>> - the items in the library are useful and good.
>> - the interfaces to the components vary.
>> - the implementation of abstract data types are
>> really hacky (in the bad sense).
>> - the performance on some of the data structures
>> promises to be not very good.

> You'll always get a bit of variance when multiple people work
> on a common project, no matter how far you go with coding
> standards.

I don't think the answer is coding standards, but a
component framework. I've just posted my (too) long
note on this.

I'm not concerned with a bit of variance, what I don't
like is the totally different paradigms people use to
accomplish what is essentially the same simple task.

Pick your five favorite packages and see how to deallocate
resources. Why are they all different? Because there's
no canonical way to do it, so everybody does it as they
see fit.

Even worse, not having a component model discourages having a library
of components (I don't know if this is a tautology or just redundant,
but it seems pretty obvious to me). If we had a standard component
system, adding a "proper" http processor or tree class becomes trivial,
since the obvious thing would also be the correct thing:

class http {
method get {} {}
etc...
}
class tree {
method insert {} {}
etc...
}

It cleanly specifies what the component does, and it is easy
to fill in the blanks with the real code.

(This seems very familiar to the arguments we went through with the
assembly language people so many years ago: "let the compiler allocate
your registers, etc...")

Take a look at the heroic code ::struct::tree has to go
through to keep track of its internal structure.

> However, you're
> guaranteeing it will be slower if you base it on itcl, so I'm
> not sure that brings any more than a bit of class structure.

I'm sorry to be blunt, but you are just plain wrong, and it's
obvious you have not actually tried this yourself. Here
are my measurements of appending items onto a list. Column 1
is the number of element appended. Column 2 is straight Tcl,
using lappend. Column 3 is itcl, lappending onto class data.
Column 4 is tcllib, using get/set.

1000 0.015023 0.014914 0.800682
2000 0.027649 0.097903 2.11605
3000 0.042296 0.043507 3.40037
4000 0.053545 0.058616 4.58981
5000 0.070992 0.072617 6.51592
6000 0.082683 0.107223 8.78791
7000 0.096833 0.11079 11.1572
8000 0.107521 0.120511 13.8236
9000 0.120698 0.13371 17.171
10000 0.153866 0.17769 22.0629
100000 1.666287 1.626071 (still running, however it just passed
27 min, running 49.22% on a dual-cpu
sun e3000)

Not to belabor the point, but get/set is obviously peturbing
the internal Tcl_Obj list state somewhere, and the non-linear
behavior of string to list conversion is kicking in.

> Those data structures which would most need speed improvements
> (like the tree) are most likely to find themselves move to C
> at some point.

Apologies again, but this is just a copout. It works great
in Perl, Python, and Itcl. Only if you were using the current
tcllib implementation would you need to recode.

What worries me as much as anything is your seeming reluctance
to actually address the real problem. Does nobody see the
value of abstract data types and a built-in component mechanism?

Mark.

Volker Hetzer

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
Mark Harrison wrote:
>
> Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> > The targeted extensions are the usual suspects: [incr Tcl], TclX,
> > BLT, expect, tcllib, and common requests like thread and more widgets.
>
> How about including itcl, and coding tcllib as itcl components?
> I'm following up with a message regarding my experience with
> the current tcllib implementation... so far, it's only been
> so-so.
Please don't make tcllib dependent on itcl. I don't want
all that class code overhead for some simple data types and commands.
Rather, if I were you (Jeff), I'd seriosly rethink the No-C approach to tcllib.

Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

vincen...@my-deja.com

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
In article <cqggd8...@swbackup.sw.asiainfo.com>,
Mark Harrison <ma...@usai.asiainfo.com> wrote:

> Jeff wrote:
> > Those data structures which would most need speed improvements
> > (like the tree) are most likely to find themselves move to C
> > at some point.
>
> Apologies again, but this is just a copout. It works great
> in Perl, Python, and Itcl. Only if you were using the current
> tcllib implementation would you need to recode.
>
> What worries me as much as anything is your seeming reluctance
> to actually address the real problem. Does nobody see the
> value of abstract data types and a built-in component mechanism?

It does seem like this kind of simple thing (abstract data types)
should be implementable in 'Tcl' without excessive speed hits. There
does seem to be a large amount of reluctance here to require the use of
Itcl, due to various somewhat fuzzy 'memory and speed overhead' issues.

Mark has given us a good example of Itcl in which there appears to be
basically no speed overhead, and a vast improvement in code readability
and maintainability (see separate thread on tcllib).

So one solution is certainly to add Itcl to the core despite apparent
reluctance in this news group. However, perhaps there is a (slightly
longer term) better solution:

Since Tcl 8.4 is going to support megawidgets, and they also require a
component mechanism of one kind or another, these two solutions should,
if possible be combined: why not add a simple megawidget/struct/class
system to core Tcl, which doesn't support real inheritance, and perhaps
not private/protected/public (well, 'protected' is meaningless without
inheritance) etc, BUT which provides all the necessary hooks so that it
can be very easily extended to become Itcl/Itk/Iwidgets.

This would satisfy the 'I don't want Itcl anywhere near my Tcl
distribution' camp, and would allow a nicely written,
understandable 'struct' package to tcllib.

Of course whether all the extra work involved is worth it (as opposed
to simply using Itcl) is another question... Not having looked at the
Itcl source for a few years, I don't know whether it would be easy to
separate Itcl classes into the required 'simple core support' and 'new
Itcl'.

just my 2 cents for monday morning...

Vince.


Sent via Deja.com http://www.deja.com/
Before you buy.

lvi...@cas.org

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to

According to Mark Harrison <ma...@usai.asiainfo.com>:
:Does nobody see the

:value of abstract data types and a built-in component mechanism?

I believe there are a number of people here on the list who see such
value - Paul Duffin has worked for a year or more on a variety of
data type issues, but the last I heard was struggling with internal
company policy to free the code. A number of individuals have written
a variety of routines on <URL: http://purl.org/thecliff/tcl/wiki/> dealing
skirting around the issues - by now there is likely some samples of
code there as well.

Andreas Kupries, Cameron Laird, Jean-Claude Wippler,
Alexandre Ferrieux, Chris Nelson, Matt Newman, and I suspect others also
have either interests, or projects, which overlap in this domain.


--
<URL: http://dev.scriptics.com/>
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

Frank Pilhofer

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
Volker Hetzer <volker...@abg1.siemens.de> wrote:
>
> Please don't make tcllib dependent on itcl. I don't want
> all that class code overhead for some simple data types and commands.
>

I would very much like to see itcl added to the core. Even now that it's
maintained by Scriptics, I feel somewhat sore about it. IMHO, Tcl is in
desperate need of an object system, both on the C and on the Tcl level.
Some applications just are not possible (well, sensible to implement)
without an object system -- CORBA is an example.

Of course, even if tcllib used [incr Tcl], it would always be an option,
and no package would actually be required to use it. But it does make life
easier for a package programmer, especially if some state is involved that
at the moment must be maintained in global arrays, indexed by a hopefully
unique id.

As mentioned in this thread, the overhead induced by itcl is minimal.

Frank


--
+ Frank Pilhofer f...@informatik.uni-frankfurt.de +
| http://www.uni-frankfurt.de/~fp/ |
+---- Life would be a very great deal less weird without you. - DA ----+

Volker Hetzer

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
Frank Pilhofer wrote:
>
> Volker Hetzer <volker...@abg1.siemens.de> wrote:
> >
> > Please don't make tcllib dependent on itcl. I don't want
> > all that class code overhead for some simple data types and commands.
> >
>
> I would very much like to see itcl added to the core. Even now that it's
> maintained by Scriptics, I feel somewhat sore about it. IMHO, Tcl is in
> desperate need of an object system, both on the C and on the Tcl level.
> Some applications just are not possible (well, sensible to implement)
> without an object system -- CORBA is an example.
TclTk das Tcl_Obj. This permits you to add constructors, copy constructors,
assignment and destructors to your data structure.
And there are Corba interfaces around.

> Of course, even if tcllib used [incr Tcl], it would always be an option,
> and no package would actually be required to use it. But it does make life
> easier for a package programmer, especially if some state is involved that
> at the moment must be maintained in global arrays, indexed by a hopefully
> unique id.

Here I'd rather see a need for a few new commands in the core that generate,
free and generally maintain strings that are unique id's. At least per interpreter.
At the moment we don't have a student available for this, but it's definitely
on our list of things to implement.

> As mentioned in this thread, the overhead induced by itcl is minimal.

I don't mean performance but the learning curve and the amount of coding.
For me, Tcl is a language to get small things done quickly. For large
things I use C++.

lvi...@cas.org

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to

I was wondering about something else relating to tcllib;

Will the tcl only extensions that have, to date, shipped with the core,
be moving to tcllib? Seems reasonable to me. I assume that in doing so,
no change would be necessary to a user's applications. It would just
be a matter of having all Tcl based extensions together in one package.

Jeffrey Hobbs

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to lvi...@cas.org
lvi...@cas.org wrote:
> Will the tcl only extensions that have, to date, shipped with the core,
> be moving to tcllib? Seems reasonable to me. I assume that in doing so,
> no change would be necessary to a user's applications. It would just
> be a matter of having all Tcl based extensions together in one package.

There are only a few Tcl-based packages in the core:
http, msgcat, tcltest and opt

opt has been superceded by cmdLine (in tcllib), http is required in
the core, in the future case where we want some sort of package
acquire system. msgcat might be used in the core in the future to
better handle localization. tcltest is questionable, and could be
moved, but unlikely since the core requires it to do regression
tests on itself. Thus, what's in the core core is really needed
by the core at this point.

Dave LeBlanc

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
Is there a point to having the tcltest package ship as part of an end
user app? Not a likely scenario for regression testing imho.

David LeBlanc

Chang LI

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to

Mark Harrison wrote in message ...

>I don't think the answer is coding standards, but a
>component framework. I've just posted my (too) long
>note on this.
>

Right, we need a component framework.

Do you think object-oriented framework is simple?
For component framework is it necessary to have inheritance in itcl?
I would like a component framework without inheritance.
I have tested namespace solution. Because namespace is not a class
you can not instance a namespace. It may cause some confusion.
Is there a list of the difference between a class and a namespace?

Finally, I would like to have a class (abstract data type) solution like
itcl
without inheritance in the Tcl component framework.

>I'm not concerned with a bit of variance, what I don't
>like is the totally different paradigms people use to
>accomplish what is essentially the same simple task.
>
>Pick your five favorite packages and see how to deallocate
>resources. Why are they all different? Because there's
>no canonical way to do it, so everybody does it as they
>see fit.
>
>Even worse, not having a component model discourages having a library
>of components (I don't know if this is a tautology or just redundant,
>but it seems pretty obvious to me). If we had a standard component
>system, adding a "proper" http processor or tree class becomes trivial,
>since the obvious thing would also be the correct thing:
>
> class http {
> method get {} {}
> etc...
> }
> class tree {
> method insert {} {}
> etc...
> }
>
>It cleanly specifies what the component does, and it is easy
>to fill in the blanks with the real code.
>
>(This seems very familiar to the arguments we went through with the
>assembly language people so many years ago: "let the compiler allocate
>your registers, etc...")
>

>Not to belabor the point, but get/set is obviously peturbing
>the internal Tcl_Obj list state somewhere, and the non-linear
>behavior of string to list conversion is kicking in.
>

>> Those data structures which would most need speed improvements
>> (like the tree) are most likely to find themselves move to C
>> at some point.
>
>Apologies again, but this is just a copout. It works great
>in Perl, Python, and Itcl. Only if you were using the current
>tcllib implementation would you need to recode.
>
>What worries me as much as anything is your seeming reluctance

>to actually address the real problem. Does nobody see the


>value of abstract data types and a built-in component mechanism?
>

Abstract data types are the kernel of the object-oriented system.
Unfortunitely manys struggle on the difficult of inheritance on an
object-oriented system. A baby itcl without class inheritance
will be much simple and useful.

schwa...@my-deja.com

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
In article <slrn8fm0...@rose.fpx.de>,

f...@informatik.uni-frankfurt.de wrote:
> Volker Hetzer <volker...@abg1.siemens.de> wrote:
> >
> > Please don't make tcllib dependent on itcl. I don't want
> > all that class code overhead for some simple data types and
commands.
> >
>
> I would very much like to see itcl added to the core. Even now that
it's
> maintained by Scriptics, I feel somewhat sore about it. IMHO, Tcl is
in
> desperate need of an object system, both on the C and on the Tcl
level.
> Some applications just are not possible (well, sensible to implement)
> without an object system -- CORBA is an example.
>
> Of course, even if tcllib used [incr Tcl], it would always be an
option,
> and no package would actually be required to use it. But it does make
life
> easier for a package programmer, especially if some state is involved
that
> at the moment must be maintained in global arrays, indexed by a
hopefully
>

I know that alot of people are opposed to adding Itcl to the core, but
it seems to me that adding it would solve 2 issues: abstract data types
(as Mark mentions) and mega-widget construction. The good thing about
having Itcl is that you *don't* have to use OO. Some of my small scripts
just use the mega-widgets. I agree this might be overkill by loading all
of the libraries, but it solves problems very fast (even faster than Tk
widgets).

How about looking at the Itcl core, and see if there is any optimization
that can be done. If there is optimization that can be done, then work
off of Itcl to add to the core. If there are no optimizations to be done
(or little), than maybe pursue other avenues.

$.02,

--brett

Jeffrey Hobbs

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to Dave LeBlanc
Perhaps not, but if we don't ship tcltest with the core, then you
can't run 'make test'....

David Cuthbert

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
I have to agree with Mark here (though I don't think I'd word my opinion
quite as strongly). Our experience at NeoLinear has been that it's a royal
pain to try to keep components from messing each other up in plain Tcl, even
when it's a group of 3-4 people sitting 20 feet from each other who are
authoring them. [incr Tcl] has been incredibly valuable in this regard.

Unfortunately, since it's not in the core distribution, we essentially
maintain our own (mostly private) Tcl distribution. This is something that
is rather costly, in terms of time spent making sure all these components
still compile and link correctly, and that our scripts move the right files
into the right places.

Like Mark, I fail to see why [incr Tcl] is so strongly opposed as a core
extension. Unlike the C vs. C++ argument, the overhead is not that great.
As for size, on my NT box the [incr Tcl] components come out to:
itcl31.dll 112k
itk31.dll 84k
lib\itcl3.1 6k
lib\itk3.1 14k

Now, [incr Widgets] is somewhat larger:
lib\iwidgets3.0.0 1.97M
and I can see why somebody might not want this in their distribution.

Finally, I've been trying to get TclCare at work. Unfortunately, the lack
of a Scriptics-maintained Itcl distribution is a bit of a sticking point
with management, and I reluctantly have to agree with their argument: "Why
should we pay for support when we'll still end up doing much of the support
ourselves?"

In the end, unless Scriptics changes its position here, I think I/we may end
up going to a parallel (publicly readable) distribution, where Tcl/Tk/[incr
Tcl]/[incr Tk]/[incr Widgets] is distributed as a complete bundle for the
Sparc and NT platforms and updated as new releases or Tcl/Tk or Itcl are
created (or time permits). Of course, I'm not implying that this is a
simple or trivial task (releasing software never is, if the customer can get
you on the other end of the phone... :-).

Dave "My Employer Disavows All Knowledge Of What I Write" Cuthbert
--
David Cuthbert
da...@kanga.org

Mark Harrison

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
Volker Hetzer <volker...@abg1.siemens.de> wrote:
> Please don't make tcllib dependent on itcl. I don't want
> all that class code overhead for some simple data types and commands.

What kind of overhead?

Memory? On sparc solaris, "package require Itcl"
adds 16% to tclsh8.3 (SZ+RSS from 4008 to 4672) and 5% to wish8.3
(SZ+RSS from 7104 to 7448).

Speed? There is an access penalty for class data. But as soon
as you hit a certain level of data complexity, you have to do
something to organize your data, and whatever you do is going
to add some kind of performance penalty.

Mental overhead (for the user)? If you take a look at the
example I posted (queue), you will see that the calling
program is unchanged. I.e.,
queue foo
queue put 1 2 3
queue size
queue clear
works identically. It should be noted that both implementations
use the popular "object" nomenclature approach:
type name
name command

Mental overhead (for the programmer)? Please take a look at the
examples I posted, and tell me which has more mental overhead.

I sincerely want to know the answers to these questions.
I hear so many bad things about Tcl (which I disbelieve),
but itcl comes in a close second.

> Rather, if I were you (Jeff), I'd seriosly rethink
> the No-C approach to tcllib.

I think Jeff is correct to defer a C-based library at this time,
although I agree with you that it is a good thing. For example,
I use both Brent's base64 and the one in Trf (Andreas, am I thinking
of the right one?). The tcl-only base64 is great for small
things, such as HTTP basic authentication, but is too slow
for processing big mime-encoded files. So for some small
tcl web apps I used the tcl version (so people can just
run without installing a binary package), but for my bigger
mime-processing application I use the C version.

Rgds,

Mark Harrison

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
Volker Hetzer <volker...@abg1.siemens.de> wrote:

> Frank Pilhofer wrote:
>> Some applications just are not possible (well, sensible to implement)
>> without an object system -- CORBA is an example.
>[...]

> And there are Corba interfaces around.

I think Frank knows this, he is the author of the Mico
and Tcl-Mico. :-)

>> As mentioned in this thread, the overhead induced by itcl is minimal.
> I don't mean performance but the learning curve and the amount of coding.
> For me, Tcl is a language to get small things done quickly. For large
> things I use C++.

Sorry for not reading ahead, this answers my previous post.
But please do compare the two versions of ::tcllib::stack
and post your comments regarding the learning curve and
amount of coding for each.

Donal K. Fellows

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
> I'm sorry to be blunt, but you are just plain wrong, and it's
> obvious you have not actually tried this yourself. Here are my
> measurements of appending items onto a list. Column 1 is the number
> of element appended. Column 2 is straight Tcl, using lappend.
> Column 3 is itcl, lappending onto class data. Column 4 is tcllib,
> using get/set.
>
> 1000 0.015023 0.014914 0.800682
> 2000 0.027649 0.097903 2.11605
> 3000 0.042296 0.043507 3.40037
> 4000 0.053545 0.058616 4.58981
> 5000 0.070992 0.072617 6.51592
> 6000 0.082683 0.107223 8.78791
> 7000 0.096833 0.11079 11.1572
> 8000 0.107521 0.120511 13.8236
> 9000 0.120698 0.13371 17.171
> 10000 0.153866 0.17769 22.0629
> 100000 1.666287 1.626071 (still running, however it just passed
> 27 min, running 49.22% on a dual-cpu
> sun e3000)

That last column looks worryingly non-linear...

> Not to belabor the point, but get/set is obviously peturbing
> the internal Tcl_Obj list state somewhere, and the non-linear
> behavior of string to list conversion is kicking in.

You are using 8.3, aren't you? 8.2 is *much* slower for this sort of
thing, but 8.3 has a monster speedup patch in there and I observe
linear timing behaviour for queue put on 8.3 on my Sun Ultra5...

(I've got an even faster version of the queue code, but I'm still
worried about the speed of the get subcommand. That's much harder to
get going really fast.)

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

Roger Schneider

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
> > Volker Hetzer <volker...@abg1.siemens.de> wrote:
> > >
> > > Please don't make tcllib dependent on itcl. I don't want
> > > all that class code overhead for some simple data types and
> commands.
> > >
> >
> > I would very much like to see itcl added to the core. Even now that
> it's
> > maintained by Scriptics, I feel somewhat sore about it. IMHO, Tcl is
> in
> > desperate need of an object system, both on the C and on the Tcl
> level.
> > Some applications just are not possible (well, sensible to implement)
> > without an object system -- CORBA is an example.
> >
> > Of course, even if tcllib used [incr Tcl], it would always be an
> option,
> > and no package would actually be required to use it. But it does make
> life
> > easier for a package programmer, especially if some state is involved
> that
> > at the moment must be maintained in global arrays, indexed by a
> hopefully
> >
>
> I know that alot of people are opposed to adding Itcl to the core, but
> it seems to me that adding it would solve 2 issues: abstract data types
> (as Mark mentions) and mega-widget construction. The good thing about
> having Itcl is that you *don't* have to use OO. Some of my small scripts
> just use the mega-widgets. I agree this might be overkill by loading all
> of the libraries, but it solves problems very fast (even faster than Tk
> widgets).
>
> How about looking at the Itcl core, and see if there is any optimization
> that can be done. If there is optimization that can be done, then work
> off of Itcl to add to the core. If there are no optimizations to be done
> (or little), than maybe pursue other avenues.
>
> $.02,
>
> --brett
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Hello,

there are some component approaches out there in the tcl community
beneath the
itcl /iwidgets approach.

Every of that component models fulfills --at least-- the "mega-widget" -
construction problem.

Adding a OO-framework, itcl for example (there is also something like
tcl++),
to a syntax free language looks a bit strange to me.

Most Tcl developers are doing GUI staff in Tck/Tk; adding a component
approach for constructing
"mega-widgets" will slow down the graphics part,
unhappily Tcl/Tk isn't fast enough to ignore the performance issue.

Following is a performance comparison for some component approaches in
Tcl/Tk 8.0:

package require Iwidgets;
namespace import iwidgets::*
update;

set t1 [time {
for {set i 0} {$i < 100} {incr i} {
pack [combobox .cbiw_$i]

}

update;
}];

# -> 2677773 microseconds per iteration

package require BWidget;
update;

set t2 [time {
for {set i 0} {$i < 100} {incr i} {
pack [ComboBox .cbbw_$i]

}

update;
}];

# -> 3831604 microseconds per iteration


package require rtl_combobox 1.2;
update;

set t3 [time {
for {set i 0} {$i < 100} {incr i} {
pack [rtl_combobox .cbrtl_$i]

}

update;
}];

# -> 909814 microseconds per iteration

package require mkWidgets;
update;

set t4 [time {
for {set i 0} {$i < 100} {incr i} {
pack [combobox .cbmw_$i]

}

update;
}];

# -> 405681 microseconds per iteration

package require Iwidgets;
namespace import iwidgets::*
update;

set t1 [time {
for {set i 0} {$i < 100} {incr i} {
pack [spinner .spiw_$i]

}

update;
}];

# -> 1337203 microseconds per iteration

package require BWidget;
update;

set t2 [time {
for {set i 0} {$i < 100} {incr i} {
pack [SpinBox .spbw_$i]

}

update;
}];

# -> 4773526 microseconds per iteration

package require rtl_spinbox;
update;

set t3 [time {
for {set i 0} {$i < 100} {incr i} {
pack [rtl_spinbox .sprtl_$i]

}

update;
}];

# -> 903368 microseconds per iteration


package require mkWidgets;
update;

set t4 [time {
for {set i 0} {$i < 100} {incr i} {
pack [spinentry .spmw_$i]

}

update;
}];

# -> 366475 microseconds per iteration

The mkWidgets are somewhat off-topic, because they do not
provide components as iwidgets, bwidgets , rtl do. On the other side the
mkWidgets time
are close to plain Tk and shows the performance degenerating i mentioned
above.

Don't misunderstand the times above as a benchmark for the component
models at all,
the implementations might be to different to state that they are based
on the component
model alone.


Kind Regards


Roger

--
======================================================================
Arndt Roger Schneider Phone: ++49-(0)6 11-17 31-6 17
Patzschke + Rasp Software AG Fax: ++49-(0)6 11-17 31-31
Bierstadter Straße 7 mailto:roger.s...@prs.de
D-65189 Wiesbaden Web Site: http://www.prs.de
======================================================================

Frank Pilhofer

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
Volker Hetzer <volker...@abg1.siemens.de> wrote:
>
> TclTk das Tcl_Obj. This permits you to add constructors, copy constructors,
> assignment and destructors to your data structure.
>

But then, Tcl_Obj's are not accessible from the Tcl level. (Wasn't there
supposed to be a Feather with something-like-this functionality?) Also,
there are currently lots of difficulties placing command objects inside a
Tcl_Obj.

>
> And there are Corba interfaces around.
>

Really? ;) But most of them ignore the object orientation paradigm and
require you to maintain the object state yourself. And then, they're
written in C, where things are a little easier with Tcl_Obj's.
Combat in fact uses [incr Tcl] for server-side scripting.

>
> I don't mean performance but the learning curve and the amount of coding.
> For me, Tcl is a language to get small things done quickly. For large
> things I use C++.
>

I wouldn't say that adding an object mechanism impacts the learning curve.
itcl objects are a pretty natural extension to Tcl. Whether procedure-based
or object-based packages are easier to use probably depends on documentation.

Mark Harrison

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
Chang LI <cha...@neatware.com> wrote:
> Do you think object-oriented framework is simple?

There are OO frameworks that are simple, and OO
frameworks that are complex.

It is similar to the often asked question, "Isn't Tcl too slow
for real work?" The answer is: it depends, sometimes yes and
sometimes no. But the person who says "Tcl is too slow for my
application, so I'm going to write my own scripting language"
is almost always mistaken.

> For component framework is it necessary to have inheritance in itcl?

For many things, no. See my stack example. For some things,
yes. I will make an example tree and post it later. It is
also interesting to contrast where inheritance is a less
good solution. I will followup with an example of that,
using Tk.

> I have tested namespace solution. Because namespace is not a class
> you can not instance a namespace. It may cause some confusion.
> Is there a list of the difference between a class and a namespace?

You have identified the main difference. Instance-specific data
is automatic with a class, and can usually be made private. With
a namespace, you typically see data stored in a common array,
indexed by the instance name.

The other main differences are automatic initialization and
deinitialization (constructors and destructors), and
inheritance.

> Finally, I would like to have a class (abstract data type) solution like
> itcl
> without inheritance in the Tcl component framework.

I am not opposed to this. But I think think a reasonable
argument can be made that in some cases an object approach
provides a better solution than a non-object approach.

BTW, it's easy to set up a framework for classes and
abstract data types (just look at how many class systems
there are for Tcl). Here' some skeleton code. If they
are still going on about "design patterns" then I want
credit for the "recursively eval body" pattern. :-)

proc class {namespace name body} {
puts "namespace eval $namespace \{"
puts " proc $name {{name \"\"}} \{"
puts " # fill this in with parse/dispatch code"
puts " \}"
eval $body
puts ""
puts "\}"
}
proc variable {name} {
puts " variable $name ;# array indexed by name"
}
proc method {name arg body} {
puts " proc _$name {$arg} \{"
puts " $body"
puts " \}"
}

# here's a test
class struct stack {
variable stacks
method clear {} {}
method peek {{count 1}} {}
method pop {{count 1}} {}
method push {arg1 args} {}
method rotate {count steps} {}
method size {} {}
}

> A baby itcl without class inheritance
> will be much simple and useful.

I would agree with "a baby tcllib without class inheritance..."
The reason I like full itcl are that it is mature, debugged,
widely used, etc... no reason to try to reinvent yet another
class extension.

Mark Harrison

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
vincen...@my-deja.com wrote:
> component mechanism of one kind or another, these two solutions should,
> if possible be combined: why not add a simple megawidget/struct/class
> system to core Tcl, which doesn't support real inheritance, and perhaps
> not private/protected/public (well, 'protected' is meaningless without
> inheritance) etc, BUT which provides all the necessary hooks so that it
> can be very easily extended to become Itcl/Itk/Iwidgets.

This is a reasonable approach, and one worth investigating. My two
concerns:

1. No matter how smart the core team is, it is going to be difficult
to match Michael's hard-won knowledge and experience in any kind
of reasonable timeframe. Itcl has been tested and found capable
on the most demanding projects[*]. It is not going to be
interesting to bump around for several releases searching for
the sweet spot.

2. In sort of a "reverse network effect", having multiple object
systems lowers the value of all of them. We can look at C++
to see what a headache it causes (e.g., multiple string classes).
But if hooks could work as you suggest to make them compatible
that does not seem to be a problem.

[*] just glance through the old conference proceedings. Almost every
"big and impressive project" paper notes that they use itcl.

Mark Harrison

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
David Cuthbert <da...@kanga.org> wrote:
> I have to agree with Mark here (though I don't think I'd word my opinion
> quite as strongly).

Strongly worded? Me? :-) Anyways, apologies all around to
unsuspecting victims everywhere... BTW, in case nobody's
noticed, I think I've got my newsfeed working again.

> Our experience at NeoLinear has been that it's a royal
> pain to try to keep components from messing each other up in plain Tcl, even
> when it's a group of 3-4 people sitting 20 feet from each other who are
> authoring them. [incr Tcl] has been incredibly valuable in this regard.

That has been my experience as well. Michael McLennan and I cover
our non-itcl approach to data abstraction in section 8.2.2
("Synthesizing data structures") of "Effective Tcl/Tk Programming".
But we both believe that as the problem gets larger, it does not
scale very well. Namespaces help, but there is a limit as to
what arrays keyed by object names can accomplish.

Speaking of Michael, let us not forget that in addition to being
the author of [incr Tcl] he is the author of Tcl namespaces.

Volker Hetzer

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
Mark Harrison wrote:
>
> Volker Hetzer <volker...@abg1.siemens.de> wrote:
> > Frank Pilhofer wrote:
> >> Some applications just are not possible (well, sensible to implement)
> >> without an object system -- CORBA is an example.
> >[...]

> > And there are Corba interfaces around.
>
> I think Frank knows this, he is the author of the Mico
> and Tcl-Mico. :-)
Ah. Didn't know that...
So far we never had to use CORBA but used a simple pure-Tcl rpc mechanism
for client server stuff.


> But please do compare the two versions of ::tcllib::stack
> and post your comments regarding the learning curve and
> amount of coding for each.

Ok, the itcl version looks better. I think, from a user point of view, you've
got me convinced.
So far I had a long look at itcl about a year ago, read the doc but couldn't
get it to compile. At that time it looked like some nice package that took
too much effort to be maintained longterm. Doc was big and itcl seemed loaded
with things we didn't need.
If it were integratd into the core I think I'd have a second look at it.

Mark Harrison

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
> That last column looks worryingly non-linear...

Indeed. Eric Melski has provided an alternate version
of the test program which speeds things up by moving
the get/set out of the for loop (appending to a temporary
variable), but I'm not convinced that's addressing the
real problem.

> You are using 8.3, aren't you? 8.2 is *much* slower for this sort of
> thing, but 8.3 has a monster speedup patch in there and I observe
> linear timing behaviour for queue put on 8.3 on my Sun Ultra5...

I believe so... I've just recently installed it and get:
% set tcl_patchLevel
8.3.0

> (I've got an even faster version of the queue code, but I'm still
> worried about the speed of the get subcommand. That's much harder to
> get going really fast.)

I would be interested in seeing it. What do you do to speed it up?

lvi...@cas.org

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to

According to David Cuthbert <da...@kanga.org>:
:Finally, I've been trying to get TclCare at work. Unfortunately, the lack

:of a Scriptics-maintained Itcl distribution is a bit of a sticking point
:with management, and I reluctantly have to agree with their argument: "Why
:should we pay for support when we'll still end up doing much of the support
:ourselves?"


What does the phrase "lack of a Scriptics maintained Itcl distribution"
mean to you?

When TclPro releases come out, there is an Itcl included. When I go
to submit a bug report, itcl is one of the options on which I can report
bugs. When I visit the Scriptics netcvs, the latest source code is
available there.

What additional support are you seeking? Have you discussed this additional
need with Scriptics?

Richard.Suchenwirth

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to Mark Harrison
Mark Harrison wrote:
[snip..]

> BTW, it's easy to set up a framework for classes and
> abstract data types (just look at how many class systems
> there are for Tcl). Here' some skeleton code. If they
> are still going on about "design patterns" then I want
> credit for the "recursively eval body" pattern. :-)
>
[..snap]

Great stuff! I put it on the Wiki for persistence, at
http://purl.org/thecliff/tcl/wiki/753.html
--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
RC DT2, Siemens Electrocom, Buecklestr. 1-5, D-78467 Konstanz,Germany
-------------- http://purl.org/thecliff/tcl/wiki//Richard*Suchenwirth
AL:The Analytical Engine worketh not! CB:What version dost thou have?

Frederic BONNET

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
Hi all,

back to life...

Chang LI wrote:
> Right, we need a component framework.
>

> Do you think object-oriented framework is simple?

> For component framework is it necessary to have inheritance in itcl?

> I would like a component framework without inheritance.

> I have tested namespace solution. Because namespace is not a class
> you can not instance a namespace. It may cause some confusion.
> Is there a list of the difference between a class and a namespace?
>

> Finally, I would like to have a class (abstract data type) solution like
> itcl
> without inheritance in the Tcl component framework.

If you want the power of OOP without the burden of classes, then a nice
alternative is prototype-based OOP. Examples of prototype-based languages are
Self and JavaScript. They provide a (IMHO) simpler and much more flexible OO
framework than most class-based frameworks.

In the latter, you have to define classes as moulds into which objects must fit.
If they don't then you have to create subclasses. You end up with such
aberrations as MFC where you have to define a distinct class for every single
dialog window you have to create, considering that each of these classes will
only have one single instance.

In the former, there is no class, instead any object can inherit and evolve
independently from any other object. You can inherit variables and methods from
an object (the prototype) and redefine them or add new ones later on.
Prototype-based OOP is much flexible because classes are often a hard task to
define and are also statically defined (like with Itcl, Java, C++... but not
with eg. Smalltalk), whereas in prototype-based systems every object can evolve
independently and dynamically. Any object can behave as a class. Thus you can
create objects dynamically, then use them as prototypes for new objects. You can
modify the prototype and the changes will appear in its children. Each child can
override its prototype's behavior.

If I had to vote for an OO framework in Tcl, I'd chose a prototype-based one
because it is very easy to emulate classes with prototypes, whereas the contrary
is much harder. Moreover, I find it closer to Tcl because it's dynamic and
loosely typed, and also to Tk: each widget can behave differently whatever its
"class" may be (button, canvas), whereas class-based OO systems are usually
designed for objects that behave the same (ie objects that behave even slightly
differently have to use a subclass).

I myself implemented a rather straightforward albeit powerful prototype-based
object system in pure Tcl, called ProtoTcl, built on namespaces (that was they
were made for at the first place). I've never released it because it was mainly
experimental and for my own use/fun/education, but it is fairly useable: I
managed to implement nearly 100% of the DOM standard with it. I also find it
quite fast for a pure-Tcl system, and I guess a C version would be much faster
and also very easy to implement. FYI the source is only 477 lines, comments
included.


See you, Fred
--
Frédéric BONNET frederi...@ciril.fr
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
George Bain


ros...@teamwave.com

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
I'm probably a bit out of date on some of this, but I wanted to check;
are we at the point yet where C extensions are going into the
standard library?

If so, I think its a no-brainer to include itcl, and then base some of
the other elements in the standard library on that. People can
choose to include it if they wish; if they want to use a standard
library routine based on Itcl, they get Itcl. The idea behind the
standard library being that if you've got one part of it installed, you
can get at any other part.

I do see the issues if it would at this point be required to bundle Itcl
into libtcl.a, which would force people using eg. embedded apps
to use it. So if we're not yet at the point of including C extensions,
then I could see the logic in holding off until that point.

As far as the "what about other object systems", my personal
opinion is, enough if enough! If you want to use them fine. If itcl is
in the standard library you're not forced to use that. But its silly not
to include one in the standard library, for advocacy reasons if
nothing else, and given the popularity of itcl, I think the choice is
absolutely clear.

--
Mark Roseman <ros...@teamwave.com>
http://www.teamwave.com
TeamWave Software Ltd.

Jeffrey Hobbs

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to Frederic BONNET

I leave the entire message included, because I would agree with Frederic
that a prototype based OOP system is a much better match for Tcl than
what [incr Tcl] currently provide. I'd be interested in seeing more
comparisons between existing implementations of OO systems for Tcl. It
is very likely that one will get included in the 8.4 distribution. Things
that must be considered:

* Speed - the solution should be in C in the end, so that we
can eek the very last cycle for end users.

* Feature set - it should have most, if not all, of what users
expect out of an OOP system, in a manner that fits in well with
Tcl. instance variables are good, the ability to do iterative
development is good. Rigidity bad. Things like protected vars
are arguably unnecessary.

* Stability - gotta know you can depend on it...

jay

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to
In article <38FB3A56...@abg1.siemens.de>,

Volker Hetzer <volker...@abg1.siemens.de> wrote:
> Frank Pilhofer wrote:
> > and no package would actually be required to use it. But it
> > does make life easier for a package programmer, especially if
> > some state is involved that at the moment must be maintained
> > in global arrays, indexed by a hopefully unique id.

> Here I'd rather see a need for a few new commands in the core that
> generate, free and generally maintain strings that are unique id's.
> At least per interpreter.

You should take a look at intgen in the Wiki on the following page:

http://mini.net/cgi-bin/wikit/727.html

That'll at least let you generate unique ids. Another good one might be
the dynamic variables thread a week or two ago; quite interesting stuff.

: jay
--
Using self-discipline, see http://www.eiffel.com/discipline

Andreas Kupries

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to

Mark Harrison <ma...@usai.asiainfo.com> writes:

> I sincerely want to know the answers to these questions. I hear so
> many bad things about Tcl (which I disbelieve), but itcl comes in a
> close second.

>> Rather, if I were you (Jeff), I'd seriosly rethink the No-C
>> approach to tcllib.

> I think Jeff is correct to defer a C-based library at this time,
> although I agree with you that it is a good thing. For example, I
> use both Brent's base64 and the one in Trf (Andreas, am I thinking
> of the right one?).

I guess so. Trf does have a base64 (de)coder and I haven't heard about
another C-based one.

--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Jeffrey Hobbs

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to David Cuthbert
David Cuthbert wrote:

>
> Jeffrey Hobbs wrote:
> > I leave the entire message included, because I would agree with Frederic
> > that a prototype based OOP system is a much better match for Tcl than
> > what [incr Tcl] currently provide.
>
> Interesting. When you mention this, I think of Python's objects (where you
> can add member variables; I don't know if you can add methods or not, but I
> guess you're including that functionality, too).

Yes, the ability to fiddle methods after initial class instantiation
would be useful, IMO.

> > * Feature set - it should have most, if not all, of what users
> > expect out of an OOP system, in a manner that fits in well with
> > Tcl. instance variables are good, the ability to do iterative
> > development is good. Rigidity bad. Things like protected vars
> > are arguably unnecessary.
>

> Out of curiosity, what do you mean by iterative development?

Well, like being able to extend a class after its initial declarations
without the whole subclassing, basically.

> My take on [incr Tcl] is that it's functional, it works, and it helped to
> speed our development considerably. While compelling, these arguments are
> probably not sufficent to promote an extension to core status. By including
> anything into the core, it's essentially saying, "This is the idiom that is
> the way."
>
> I'm not so concerned as to whether Itcl goes into the core or not. But I'm
> definitely of the opinion that Tcl needs an object system in its core,
> whether it's [incr Tcl] or some other implementation.

That is the basically feeling here. We would like to see some sort of
OO model in the core distribution for 8.4 (not the core, just the
distribution - which means you'd have to package require it). [incr Tcl]
is the most used, but is that because it is the best, or just because it
had the ball rolling? I'm going to keep an open mind on it, but having
used it myself I do have nits that would have to be addressed before
making it really buddy-buddy with the core.

Why do we need an OO system? We have a mature Tcl kernel. We are
looking at extending additions like tcllib and creating a core Tk
megawidget system. I believe that both of these would benefit from
being able to rely on one OOP model, and we want it to be fast (read:
C implementation).

David Cuthbert

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
lvi...@cas.org wrote:
> According to David Cuthbert <da...@kanga.org>:
> :Finally, I've been trying to get TclCare at work. Unfortunately, the lack
> :of a Scriptics-maintained Itcl distribution is a bit of a sticking point
> :with management [...]

>
> What does the phrase "lack of a Scriptics maintained Itcl distribution"
> mean to you?

Well, I can download all three (Tcl, Tk, Itcl), no problem. However, when I
go to build, there are often problems when I try to build Itcl. The
Itcl/Itk/Iwidgets man pages do not get included in the Windows Help file.
Dumb little things like that. Not terribly hard to fix, but it does take
some time (which is what management cares about).

> When TclPro releases come out, there is an Itcl included.

Right, but that is TclPro, not Tcl. We will be integrating TclPro into our
environment once TclPro 1.4 comes out, so much of this will -- hopefully! --
become moot at work. At home, well... I'll still be grabbing things through
CVS and building the latest and greatest (and crashing my build environment
:-).

> What additional support are you seeking? Have you discussed this additional
> need with Scriptics?

I was considering getting TclCare support (and Scriptics' sales has been
extremely responsive to our needs). We're pretty heavily into [incr Tcl],
so it would not make sense to get support if it doesn't include Itcl.
Unfortunately, the price tag for the premium level of support (the only
level that includes Itcl) is more than the available budget for my project.
:-(

Hopefully, we will be able to afford this level of support in the future. I
certainly have no qualms about investing (and I view this arrangement as an
investment) that amount of money in Scriptics given the returns (savings in
development time and cost, more flexibility in our tools, etc.) and would do
so today if I could.
--
David Cuthbert
da...@kanga.org

Chia-Wei Chow

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
>How about including itcl, and coding tcllib as itcl components?
>
i've never used tcllib. can someone tell me what that is?
is it a Tcl-based lib or a C-based lib? is there somewhere
i can read more about it?

i'm also not sure what Mark means by the above statement.
is he talking about expanding Tcl core commands to include
itcl commands? this message thread looks very interesting.
and I just want to understand what the hang-ups are.

As an end-user, I value Itcl very much. It is an integral
part of our projects. the main reason that we purchase TclPro
was because it had Itcl in its distribution so we don't have
to keep up with the releases and build them ourselves. to have
the ability to be OO in core Tcl will be great. by the way,
i don't really understand why Scriptics is against the idea.
isn't Tk basically an OO approach?

c.w.

~~~ ~~~
Chia-Wei Chow
~~~ /W\ ~~~ Member of Technical Staff
/ \ /\ Aerospace Simulation & System Test
Center
/\ / \/ \ Boeing
/ \/ \ \ 5301 Bolsa Ave MS: H022-F356
/ / \ \ @..@ Huntington Beach, CA 92647
/ / \ \ (--) phone: (714)934-0208
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fax: (714)934-0260
<:)))>< <:)))>< email: chia-w...@boeing.com
<:)))>< ><(((;> <:)))><
<:)))>< <:)))><

David Cuthbert

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs wrote:
> I leave the entire message included, because I would agree with Frederic
> that a prototype based OOP system is a much better match for Tcl than
> what [incr Tcl] currently provide.

Interesting. When you mention this, I think of Python's objects (where you
can add member variables; I don't know if you can add methods or not, but I
guess you're including that functionality, too).

I got into a few messy corners using this approach to subclassing;
specifically, what I thought was going to be a singly instantiated leaf
ended up getting subclassed later on.

> * Feature set - it should have most, if not all, of what users
> expect out of an OOP system, in a manner that fits in well with
> Tcl. instance variables are good, the ability to do iterative
> development is good. Rigidity bad. Things like protected vars
> are arguably unnecessary.

Out of curiosity, what do you mean by iterative development?

My take on [incr Tcl] is that it's functional, it works, and it helped to


speed our development considerably. While compelling, these arguments are
probably not sufficent to promote an extension to core status. By including
anything into the core, it's essentially saying, "This is the idiom that is
the way."

I'm not so concerned as to whether Itcl goes into the core or not. But I'm
definitely of the opinion that Tcl needs an object system in its core,
whether it's [incr Tcl] or some other implementation.

--
David Cuthbert
da...@kanga.org

David Steuber

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Has anyone looked at CLOS? I am still very new to Tcl, but it seems
to me that Tcl shares certain features with Common Lisp. While Tcl
calles the objects it works with 'strings', they are not too unlike
the lists that Lisp deals with. Also, Tcl variables (for lack of a
better name) seem to not be so untyped as the documentation suggests.

Suppose you have a Tcl object foo:

set foo {prop1 prop2 prop3 method1 method2 method3}

If prop1, prop2,prop3,method1,method2, & method3 are Tcl objects that
can be dereferenced via foo, you have basicly a bag of objects and
methods in foo. If method1 has some way of knowing that it is in the
context of foo, then it can accesss prop1 directly.

Being able to add and replace objects in foo can be pretty powerful.
Redefining method1, for example, gives you a form of polymorphism.

If you want inheritance, you could possibly do something like this:

set bar {foo prop method}

The object foo is contained in bar.

The whole #! is rather dynamic. There is no fixed structure or set
typology or taxonomy. While rigid hierarchies work well for a
compiled language like C++, a dynamic language like Tcl doesn't really
need or want them. Tcl, Perl, Common Lisp (not really a scripting
language), Python, etc have the inherent property that data and
program code are the same thing. The value func can be evaluated as
code after it has been defined. The proc keyword does something like
this. eg

set func proc {arg1 arg2} {body}
eval $func par1 par2

It seems to me, from a newbie and perhaps naive pov, that what you are
looking for is not so much an object system, but rather the
appropriate syntactic suger to make one convinient to use and faster
to execute.

When data == code {powerful stuff happens}

--
David Steuber | Hi! My name is David Steuber, and I am
NRA Member | a hoploholic.

http://www.packetphone.org/

According to Kentucky state law, every person must take a bath at least
once a year.

Chang LI

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to

Mark Harrison wrote in message ...
>Chang LI <cha...@neatware.com> wrote:


>> I have tested namespace solution. Because namespace is not a class
>> you can not instance a namespace. It may cause some confusion.
>> Is there a list of the difference between a class and a namespace?
>

>You have identified the main difference. Instance-specific data
>is automatic with a class, and can usually be made private. With
>a namespace, you typically see data stored in a common array,
>indexed by the instance name.
>

Yes. The common array often cause troubles when you build a big program.
It acts like a global variable. That is one reason I do not satisfy the
namespace
solution.

>The other main differences are automatic initialization and
>deinitialization (constructors and destructors), and
>inheritance.
>

I believe that inheritance, constructors and destructors are most
confusion and difficult to handle mechanisms in the OO language.
Many programmers cost too much time to get these ideas clear
in their minds. C++, Java, itcl all include these standard OO
behaviors.

> # here's a test
> class struct stack {
> variable stacks
> method clear {} {}
> method peek {{count 1}} {}
> method pop {{count 1}} {}
> method push {arg1 args} {}
> method rotate {count steps} {}
> method size {} {}
> }
>

I like this uniform representation. It clearly represents the
abstraction data type. The usage of "namespace eval"
is not readable and not quite clear in methodology.

>> A baby itcl without class inheritance
>> will be much simple and useful.
>
>I would agree with "a baby tcllib without class inheritance..."
>The reason I like full itcl are that it is mature, debugged,
>widely used, etc... no reason to try to reinvent yet another
>class extension.
>

What I mean is a itcl subset which eleminates the inheritance,
constructor, destructor and other difficult to use components.
The implementation will be much simple and the learning curve
is fast.


Chang LI
cha...@neatware.com
http://www.neatware.com

Chang LI

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to

Frederic BONNET wrote in message <38FC8A0A...@ciril.fr>...

>If you want the power of OOP without the burden of classes, then a nice
>alternative is prototype-based OOP. Examples of prototype-based languages
are
>Self and JavaScript. They provide a (IMHO) simpler and much more flexible
OO
>framework than most class-based frameworks.
>

>In the former, there is no class, instead any object can inherit and evolve
>independently from any other object. You can inherit variables and methods
from
>an object (the prototype) and redefine them or add new ones later on.
>Prototype-based OOP is much flexible because classes are often a hard task
to
>define and are also statically defined (like with Itcl, Java, C++... but
not
>with eg. Smalltalk), whereas in prototype-based systems every object can
evolve
>independently and dynamically. Any object can behave as a class. Thus you
can
>create objects dynamically, then use them as prototypes for new objects.
You can
>modify the prototype and the changes will appear in its children. Each
child can
>override its prototype's behavior.
>

Sounds interesting. Suppose I have a label widget and a entry widget
(object) how
could I specify them as a new widget (object)? So there are multiple
inheritances,
right? This is not an example of inheritance. It is a container.

>If I had to vote for an OO framework in Tcl, I'd chose a prototype-based
one
>because it is very easy to emulate classes with prototypes, whereas the
contrary
>is much harder. Moreover, I find it closer to Tcl because it's dynamic and
>loosely typed, and also to Tk: each widget can behave differently whatever
its
>"class" may be (button, canvas), whereas class-based OO systems are usually
>designed for objects that behave the same (ie objects that behave even
slightly
>differently have to use a subclass).
>


Chang

Volker Hetzer

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
jay wrote:
>
> In article <38FB3A56...@abg1.siemens.de>,
> Volker Hetzer <volker...@abg1.siemens.de> wrote:
> > Here I'd rather see a need for a few new commands in the core that
> > generate, free and generally maintain strings that are unique id's.
> > At least per interpreter.
>
> You should take a look at intgen in the Wiki on the following page:
>
> http://mini.net/cgi-bin/wikit/727.html
>
> That'll at least let you generate unique ids. Another good one might be
> the dynamic variables thread a week or two ago; quite interesting stuff.
Looked at it. It's not exactly what I wanted because sometimes we generate
extremely many ID's over several weeks so that we need to "free" and
reuse them too, without an overblowing stack. At the moment I think of using
AVL trees holding intervals of free ID's.

Maurice Diamantini

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
On Tue, 18 Apr 2000 22:06:01 -0700, Jeffrey Hobbs
<jeffre...@scriptics.com> wrote:

>David Cuthbert wrote:
>>
>> I'm not so concerned as to whether Itcl goes into the core or not.
>> But I'm definitely of the opinion that Tcl needs an object system in
>> its core, whether it's [incr Tcl] or some other implementation.
>
>That is the basically feeling here. We would like to see some sort of
>OO model in the core distribution for 8.4 (not the core, just the
>distribution - which means you'd have to package require it).

I aggree.
- I've never use itcl because it is a C extension which it is not
in the TCL core,
- I've never use stooop (which is a TCL only extension)
because it modify the "proc" command.

But I like a "standard" OOP package into the tcllib.


>[incr Tcl]
>is the most used, but is that because it is the best, or just because it
>had the ball rolling?

I think its probably the second point!


>... We are


>looking at extending additions like tcllib and creating a core Tk
>megawidget system. I believe that both of these would benefit from
>being able to rely on one OOP model, and we want it to be fast (read:
>C implementation).


Great news!

--
Maurice.D...@ensta.fr - ENSTA/LMA
École Nationale Supérieure de Techniques Avancées
Laboratoire de Mathématiques Appliquées
http://www.ensta.fr/~diam

Donal K. Fellows

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
In article <qe8jd8...@swbackup.sw.asiainfo.com>,

Mark Harrison <ma...@usai.asiainfo.com> wrote:
> Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>> (I've got an even faster version of the queue code, but I'm still
>> worried about the speed of the get subcommand. That's much harder to
>> get going really fast.)
>
> I would be interested in seeing it. What do you do to speed it up?

I supply the patch I've got applied. It seems to be faster,
especially when adding large numbers of elements at once.

--- Begin /tmp/queue.patch -------------------------------------------
*** tcllib0.3/struct/queue.tcl Tue Apr 11 23:11:05 2000
--- lib/tcllib0.3/struct/queue.tcl Tue Apr 18 10:28:35 2000
***************
*** 139,144 ****
--- 139,145 ----
# item first count items from the queue; if there are not enough
# items in the queue, throws an error.

+ proc ::struct::queue::K {x y} {set x}
proc ::struct::queue::_get {name {count 1}} {
variable queues
if { $count < 1 } {
***************
*** 152,158 ****
if { $count == 1 } {
# Handle this as a special case, so single item gets aren't listified
set item [lindex $queues($name) 0]
! set queues($name) [lreplace $queues($name) 0 0]
return $item
}

--- 153,161 ----
if { $count == 1 } {
# Handle this as a special case, so single item gets aren't listified
set item [lindex $queues($name) 0]
! set queues($name) \
! [lreplace [K $queues($name) [set queues($name) {}]] 0 0]
! #set queues($name) [lreplace $queues($name) 0 0]
return $item
}

***************
*** 159,165 ****
# Otherwise, return a list of items
set index [expr {$count - 1}]
set result [lrange $queues($name) 0 $index]
! set queues($name) [lreplace $queues($name) 0 $index]

return $result
}
--- 162,170 ----
# Otherwise, return a list of items
set index [expr {$count - 1}]
set result [lrange $queues($name) 0 $index]
! set queues($name) \
! [lreplace [K $queues($name) [set queues($name) {}]] 0 $index]
! #set queues($name) [lreplace $queues($name) 0 $index]

return $result
}
***************
*** 212,220 ****
if { [llength $args] == 0 } {
error "wrong # args: should be \"$name put item ?item ...?\""
}
! foreach item $args {
! lappend queues($name) $item
! }
return
}

--- 217,226 ----
if { [llength $args] == 0 } {
error "wrong # args: should be \"$name put item ?item ...?\""
}
! eval [list lappend queues($name)] $args
! #foreach item $args {
! # lappend queues($name) $item
! #}
return
}

--- End /tmp/queue.patch ---------------------------------------------

Richard.Suchenwirth

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to Donal K. Fellows
"Donal K. Fellows" wrote:
>
> + proc ::struct::queue::K {x y} {set x}
Just playing Prolog, you could also say
proc ::struct::queue::K {x _} {set x}
Legal Tcl. The underscore may even be used multiple times:
% proc K {_ _ _} {puts hi}
% K
no value given for parameter "_" to "K"
% K .
no value given for parameter "_" to "K"
% K a b c
hi
But with one single proc "clause", this doesn't help that much...

Donal K. Fellows

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
In article <38FD0487...@sim.ssd.bna.boeing.com>,

Chia-Wei Chow <ch...@sim.ssd.bna.boeing.com> wrote:
>> How about including itcl, and coding tcllib as itcl components?
>
> i've never used tcllib. can someone tell me what that is?
> is it a Tcl-based lib or a C-based lib? is there somewhere
> i can read more about it?

You can get a snapshot at http://dev.scriptics.com/software/tcllib
though since its version number is 0.3 (well, it was yesterday) I
wouldn't want to rely on it too heavily as yet.

[...]


> isn't Tk basically an OO approach?

Tk is primarily OO, but not entirely since it does not have any
inheritance. In the presence of Tk's extremely simple-to-use
callbacks, I'm not really convinced that inheritance is really needed
all that much. Perhaps someone eloquent could persuade me otherwise?

Peter.DeRijk

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
: David Cuthbert wrote:
:>
:> Jeffrey Hobbs wrote:
:> > I leave the entire message included, because I would agree with Frederic
:> > that a prototype based OOP system is a much better match for Tcl than
:> > what [incr Tcl] currently provide.
:>
:> Interesting. When you mention this, I think of Python's objects (where you
:> can add member variables; I don't know if you can add methods or not, but I
:> guess you're including that functionality, too).

: Yes, the ability to fiddle methods after initial class instantiation
: would be useful, IMO.

essential, IMHO

:> > * Feature set - it should have most, if not all, of what users


:> > expect out of an OOP system, in a manner that fits in well with
:> > Tcl. instance variables are good, the ability to do iterative
:> > development is good. Rigidity bad. Things like protected vars
:> > are arguably unnecessary.
:>
:> Out of curiosity, what do you mean by iterative development?

: Well, like being able to extend a class after its initial declarations


: without the whole subclassing, basically.

:> My take on [incr Tcl] is that it's functional, it works, and it helped to


:> speed our development considerably. While compelling, these arguments are
:> probably not sufficent to promote an extension to core status. By including
:> anything into the core, it's essentially saying, "This is the idiom that is
:> the way."

:>
:> I'm not so concerned as to whether Itcl goes into the core or not. But I'm


:> definitely of the opinion that Tcl needs an object system in its core,
:> whether it's [incr Tcl] or some other implementation.

: That is the basically feeling here. We would like to see some sort of
: OO model in the core distribution for 8.4 (not the core, just the

: distribution - which means you'd have to package require it). [incr Tcl]


: is the most used, but is that because it is the best, or just because it

: had the ball rolling? I'm going to keep an open mind on it, but having


: used it myself I do have nits that would have to be addressed before
: making it really buddy-buddy with the core.

I suppose there are many object oriented extensions to Tcl available
because many people do not like the way [incr Tcl] works. (I am also
guilty of making one, new version coming RSN). The ITcl OO model comes
from C++, a strongly typed, compiled language, and as such does not fit
into the Tcl model gracefully, IMO. I fully agree with the posters
that say a more dynamic OO models is a better fit. I can change code
on the fly in Tcl, why not classes and objects.

: Why do we need an OO system? We have a mature Tcl kernel. We are


: looking at extending additions like tcllib and creating a core Tk
: megawidget system. I believe that both of these would benefit from
: being able to rely on one OOP model, and we want it to be fast (read:
: C implementation).

speed is very important. If the system is to slow, people will often
refrain from using it, especially for these smaller extensions.

BTW, I would also advokate allways using a construct like "self method"
or "$object method" to invoke methods from within a method, instead of
the name of the method alone as in ITcl. This gets very annoying if you
want eg. to create a method "set", and have to change every occurence
of set in ::set within the methods.

--
Peter De Rijk der...@uia.ua.ac.be
<a href="http://rrna.uia.ac.be/~peter/">Peter</a>
To achieve the impossible, one must think the absurd.
to look where everyone else has looked, but to see what no one else has seen.

Peter.DeRijk

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
David Cuthbert <da...@kanga.org> wrote:
: I have to agree with Mark here (though I don't think I'd word my opinion
: quite as strongly). Our experience at NeoLinear has been that it's a royal

: pain to try to keep components from messing each other up in plain Tcl, even
: when it's a group of 3-4 people sitting 20 feet from each other who are
: authoring them. [incr Tcl] has been incredibly valuable in this regard.

: Unfortunately, since it's not in the core distribution, we essentially
: maintain our own (mostly private) Tcl distribution. This is something that
: is rather costly, in terms of time spent making sure all these components
: still compile and link correctly, and that our scripts move the right files
: into the right places.

: Like Mark, I fail to see why [incr Tcl] is so strongly opposed as a core
: extension. Unlike the C vs. C++ argument, the overhead is not that great.
: As for size, on my NT box the [incr Tcl] components come out to:

Many oppose inclusion in the core (distribution) of ITcl because it
would be to much like an official "blessing" as THE Tcl OO system.
Any other object system should give you the advantages of ITcl. Other
OO systems better fitting the Tcl phylosophy might give more advantages.

Peter.DeRijk

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
ros...@teamwave.com wrote:
: I'm probably a bit out of date on some of this, but I wanted to check;

: are we at the point yet where C extensions are going into the
: standard library?

: If so, I think its a no-brainer to include itcl, and then base some of
: the other elements in the standard library on that. People can
: choose to include it if they wish; if they want to use a standard
: library routine based on Itcl, they get Itcl. The idea behind the
: standard library being that if you've got one part of it installed, you
: can get at any other part.

: I do see the issues if it would at this point be required to bundle Itcl
: into libtcl.a, which would force people using eg. embedded apps
: to use it. So if we're not yet at the point of including C extensions,
: then I could see the logic in holding off until that point.

I thought the idea was that even at that point, the extensions should
be available in a C version as well as a Tcl-only version.

: As far as the "what about other object systems", my personal


: opinion is, enough if enough! If you want to use them fine. If itcl is
: in the standard library you're not forced to use that. But its silly not
: to include one in the standard library, for advocacy reasons if
: nothing else, and given the popularity of itcl, I think the choice is
: absolutely clear.

If popularity were the criterium, we would be using perl as a scripting
language. Seriously, it might take some more time to design a (yet
another) new OO system, but I believe it is extremely important that
the "standard Tcl OO extension" befits the simple, yet flexible and
dynamic nature of Tcl.

George A. Howlett

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs wrote:

> I leave the entire message included, because I would agree with Frederic
> that a prototype based OOP system is a much better match for Tcl than
> what [incr Tcl] currently provide.

By what measure? The inverse of its popularity and maturity?

This is simply the old CLOS slots-based vs. C++ classes OOP argument. If you
buy your CTO's argument that "people vote with their feet", it's been settled
for a lot of people a long time ago. Class-based systems (C++ and Java in
general and [incr Tcl] in specific) have more popularity and acceptance than
the slots-based systems.

It's true that the CLOS model is very flexible and dynamic. You can easily
add methods and data fields on-the-fly. Lots of programmers, myself included,
like it because you can code by the seat of your pants. But all that flexibility
and dynamic behavior doesn't make for a very good framework.

In a class-based system, the class is the blue print that tells you everything
you need to know about the object. In the slots-based system, introspection
is a necessity, since individual object can "evolve" (change their methods and
data members). This dynamic behavior can be counter-productive because it means
that objects must spend more time negotiating (dynamic binding). Object A may
have evolved into something that Object B can't deal with (forget about the
programmer).

I know some people like the slots approach because it lets you tinker with any
object. It's easy to slip another method under the hood, while with class-based
systems you have to derive a new class. This issue is moot, since [incr Tcl]
lets you do it both ways.

> I'd be interested in seeing more
> comparisons between existing implementations of OO systems for Tcl. It
> is very likely that one will get included in the 8.4 distribution. Things
> that must be considered:
>
> * Speed - the solution should be in C in the end, so that we
> can eek the very last cycle for end users.
>

> * Feature set - it should have most, if not all, of what users
> expect out of an OOP system, in a manner that fits in well with
> Tcl. instance variables are good, the ability to do iterative
> development is good. Rigidity bad. Things like protected vars
> are arguably unnecessary.
>

> * Stability - gotta know you can depend on it...

By your criteria it should be an easy choice. [incr Tcl] is a hands down winner.
Michael McLennan has been very careful to tweak the performance. For example,
access to class members is inlined, so in many cases it can be lots faster than
the equivalent Tcl-only code.

You might add one more item to your checklist.

* User base - why switch to yet another OO system when so many Tcl users
have been using [incr Tcl] for the last 7 years.

I think the question is how you would rather spend your time. You could build yet
another object system that may someday become as stable (mature and feature filled)
as [incr Tcl]? It might even make it into the 8.4 release schedule. But if
it was my choice, I'd rather get to all the other items on the 8.4 wish list?

--gah

ros...@teamwave.com

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to

> If popularity were the criterium, we would be using perl as a
> scripting language. Seriously, it might take some more time to
> design a (yet another) new OO system, but I believe it is
> extremely important that the "standard Tcl OO extension" befits
> the simple, yet flexible and dynamic nature of Tcl.


I don't believe that itcl is complex, nor inflexible as an object
system. Yes its a bit more complex than straight Tcl, but so is any
object system. Have you actually tried it out for any real project?

Remember that all end users won't be using it (directly) if its there.
Mark Linton used to argue that inheritance etc. were of great
benefit to component builders, not component users. Its the
people building the stacks and queues who would need to know
about those features, not the people using the stacks and queues
in their programs. We're giving the tools to the people who need
them, who probably already know about inheritance etc. As we've
demonstrated, the API's remain the same no matter how we're
building them underneath.

Its mildly painful to explain to people that Tcl isn't OO, but you can
grab extension X, Y or Z to suit your needs. But making the
"standard" OO extension one that doesn't support all the familiar
concepts that people expect would make us even more of a
laughing stock. Remember, most people use several
programming languages, and the odds are the ones they're
already using support class/inheritance based OO.

Again, this doesn't preclude using an alternate object system, nor
would I want to do that. But I figure for most people, most of the
time, itcl is a good match.


--
Mark Roseman <ros...@teamwave.com>
http://www.teamwave.com
TeamWave Software Ltd.

Paul Duffin

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs wrote:
>
> Why do we need an OO system? We have a mature Tcl kernel. We are
> looking at extending additions like tcllib and creating a core Tk
> megawidget system. I believe that both of these would benefit from
> being able to rely on one OOP model, and we want it to be fast (read:
> C implementation).
>

OO systems tend to fall between the following extremes

Rigid Flexible
Fast Slow
Small Objects Large Objects

Rigid OO systems tend to be faster and have smaller objects than more flexible
OO systems. As always there is a trade off to be made between these different
approaches.

Also, what does an object look like ? Is it a Tcl command like Tk widgets and
[incr Tcl] objects ? Are the objects automatically freed, or do they have to
be explicitly freed ?

Should the data types be part of the OOP or should they be distinct ? IMO
they should not be part of the OOP and should be similar in use to lists. If
an OOP version is needed it is relatively easy to wrap them in an OOP wrapper.

This is a very important decision and a lot of thought is needed before it can
be made.

Mark Harrison

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>> isn't Tk basically an OO approach?

> Tk is primarily OO, but not entirely since it does not have any
> inheritance. In the presence of Tk's extremely simple-to-use
> callbacks, I'm not really convinced that inheritance is really needed
> all that much. Perhaps someone eloquent could persuade me otherwise?

I certainly agree with this. The drawback we have seen so far
has to do with megawidgets (composite widgets). One problem
is that modifying an attribute of the megawidget causes a lot of
overhead as the attribute information is passed down the hierarchy.

It's been a pretty well discussed problem, and kudos to
Jeffrey for biting the bullet and addressing it in 8.4.

Ludwig Callewaert

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to

Donal K. Fellows wrote in message <8dk10r$r6a$1...@m1.cs.man.ac.uk>...
> ......

>Tk is primarily OO, but not entirely since it does not have any
>inheritance. In the presence of Tk's extremely simple-to-use
>callbacks, I'm not really convinced that inheritance is really needed
>all that much. Perhaps someone eloquent could persuade me otherwise?
>
>Donal.

Well I do not know whether I am eloquent or not, since I do not even know
the meaning of the word :-)
Nevertheless, I will give you an example where I see inheritance being
usefull for Tk.
Suppose you want to implement a text widget with an undo and redo stack.
The way you can currently do it is by renaming the basic text widget
procedure after
creation and putting your own in place which traps the insert and delete
'messages'.
The drawback being a performance loss, which can be serious if you use the
widget procedure heavily (I know, I have been there).

With inheritance you could derive your text widget from the Tk one and
overload
the insert and delete message. This is not only cleaner, but also has a
performance
advantage, at least if the OO system has been implemented properly.

Ludwig.

Mark Harrison

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Peter.DeRijk <der...@hgins.uia.ac.be> wrote:
> Many oppose inclusion in the core (distribution) of ITcl because it
> would be to much like an official "blessing" as THE Tcl OO system.
> Any other object system should give you the advantages of ITcl. Other
> OO systems better fitting the Tcl phylosophy might give more advantages.

Unfortunately, object systems suffer from the "reverse network effect".
The more you have, the less valuable any of them are. We can see
this problem in C++, where any number of class libraries implement
incompatible versions of basic object types, such as strings and
lists.

By the time STL was introduced, many projects/groups were at
a stage where changing class libraries was not feasible.

[incr Tcl] has been around so long (one of the first Tcl
extensions available), and is so widely used and supported,
it is just hard to consider other options.

Dozens of object packages have appeared over the years because
it is so easy to do... you can the simple skeleton code I
posted yesterday. Believe it or not, [incr Tcl] started out
as a 400 line Tcl script. Over the years, it has matured
to its present robust state. Do you like namespaces? It
came from itcl. Think the implementation is good? Personally
hand-coded by Michael.

Bob Techentin

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs wrote:
>
> David Cuthbert wrote:
> >
> > Jeffrey Hobbs wrote:
> > >
> > > * Feature set - it should have most, if not all, of what users
> > > expect out of an OOP system, in a manner that fits in well with
> > > Tcl. instance variables are good, the ability to do iterative
> > > development is good. Rigidity bad. Things like protected vars
> > > are arguably unnecessary.
> >
> > Out of curiosity, what do you mean by iterative development?
>
> Well, like being able to extend a class after its initial declarations
> without the whole subclassing, basically.

For me, [Itcl] has just about all the features that I expect out of an
OO system, with the exception of shadow coupling to C++, for which I
turn to SWIG.

I'm not so sure that dynamically changing the structure of objects after
instantiation is such a great feature. I'm not versed in "slot-based"
systems described by George A. Howlett in a nearby thread, but I do not
believe that I would get a huge benefit from this feature. I can
subclass and extend an [Itcl] class so quickly with so little code that
I can't imagine object level flexibility providing much benefit.

I can't imagine wanting to add new code to a proc without redefining the
whole proc. And it is so easy to redefine the whole proc, why would I
want to bother?


<off topic>
By the way, "iterative development" means something else to me. I've
been using Rational software tools for OO analysis and design for a few
years now, and following the development of UML and the writings of the
"three amigos". To me, "iterative development" means that you drive
your product to regular functional releases as a part of long term
development, like the Mozilla milestone releases.

Maybe we're on the verge of coining a new term. Something like "dynamic
development" or some catchy phrase to describe that heady feeling we all
get when the inherent speed and power of scripting languages and the
special features of Tcl (command replacement, introspection, etc.) come
together and we tinker our way to a software solution. But "power
tinkering" isn't exactly the buzz phrase I had hoped for. :-)
</off topic>


> [incr Tcl]
> is the most used, but is that because it is the best, or just because it
> had the ball rolling? I'm going to keep an open mind on it, but having
> used it myself I do have nits that would have to be addressed before
> making it really buddy-buddy with the core.

I was sort of under the impression that Itcl's object model evolved from
Tk. Even though J.O. made a point in his 1991 USENIX paper that Tk has
an "object-like feel" but "not strongly object-oriented", Michael
McLennan describes Itcl with "This might look familiar." It seems to me
that they evolved together, and they seem to fit together pretty well.
Itcl's class system sets up a pretty good framework for OO development.
The slow bits are written in C. There is plenty of class/object
introspection. What is missing?

Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html

Mark Harrison

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> I'd be interested in seeing more
> comparisons between existing implementations of OO systems for Tcl. It
> is very likely that one will get included in the 8.4 distribution. Things
> that must be considered:

> * Speed - the solution should be in C in the end, so that we
> can eek the very last cycle for end users.

Itcl has been tuned a lot over the years, in the face of implementing
numerous real-world mission-critical systems. And surely you can
see that itcl is going to have an definite performance advantage
over any slot-based system, since it can use its a priori knowledge
to treat instance variables as "compiled local" variables.

It's way too complicated to go into right now, but surely you know
that a slot-based system is going to hit the same problem as
"upvar"... you will have at least two hash table hits, whereas
with the "compiled local" you don't have any hash table hits
at all, just an integer index. Do you remember how Brian
Lewis mentioning that declaring variable "global" instead of
using namespace scoping "::" made things faster? Same trick.

Just the fact that these things are known and taken advantage
of in the itcl code should convince us that itcl has had
orders of magnitudes of performance tuning over any of the
other object systems proposed.

Don't forget, where did namespaces come from? Michael did
it to optimize itcl 1.5 in 1995. No matter how much smarter
somebody is than Michael (and that is a pretty high standard),
it is going to take a long time to approach anywhere near that
level of code maturity.

Other arguments abound. What other object systems have built-in
hooks to implement method bodies in C/C++? Could this have
something to do with the fact that Michael himself works with
seriously memory and CPU intensive tasks such as CAD modelling?

> * Feature set - it should have most, if not all, of what users
> expect out of an OOP system, in a manner that fits in well with
> Tcl. instance variables are good, the ability to do iterative
> development is good. Rigidity bad.

Itcl has a feature set that has been subjected to rigorous review
over the past eight years. It is based on C++. There are several
people who prefer the CLOS/Self model, but few of those espousing
that view seem to have a large-scale OO project to back it up,
whereas Itcl has numerous large-scale success stories and design
wins. Not to stretch the point too much, but almost all of the
really impressive "big mission critical project done with Tcl"
stories are actually "big mission critical project done with Itcl"
stories.

In addition, Don't underestimate the value of having an object
model that is widely accepted. Anybody trained in C++ or Java
can look at an Itcl class and immediately know what is going on.
Self and CLOS (and even Smalltalk?) were the losers in the OO
war, and attempting to refight that battle is just not interesting.

> Things like protected vars
> are arguably unnecessary.

Sure, if you plan to never use inheritance. Buy an OO book! ;-)


> * Stability - gotta know you can depend on it...

See the above comments. It's not only the most popular
tcl oo extension for mission critical applications on the
planet, it's the most popular one in the solar system, right?

I've got more to say, but the front gate locks at 11:00PM, and
I just got the warning that if I don't leave right now I'll
have all night to post at my leisure...

Cheers,

Donal K. Fellows

unread,
Apr 19, 2000, 3:00:00 AM4/19/00