OOP system for Tcl8.4

18 views
Skip to first unread message

Jeffrey Hobbs

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Just to make a few things clear where the lines seem to have blurred...

The core team decided that it was time for an OOP system in the core
distribution, and to put it in with Tcl8.4. Whatever the choice is,
it will be included in the distribution, but to get it you will have
to do 'package require oosystem*', and it will have a separate dll.
This is part of expanding Tcl's reach by modularization (without
kernel bloat). For example, the 'thread' extension will be part of
the Tcl8.4 distribution as well.

The reasons behind the need of an OOP system were for use in a
megawidget system, and perhaps parts of tcllib. That means if you
were to use these, they would implicitly require the OOP extension.

[incr Tcl] is recognized as the most popular, and likely most
robust OOP system for Tcl currently. However, some people are
voicing their opinions against it as a choice (see the CLOS, or
slots-based, vs C++/class-based discussions). I invite everyone to
take part in these discussions, as we are reading every line. This
is everyone's time to shape the future of Tcl.

The core team realizes that any choice is going to make some people
unhappy (OO argument have been around a long time, and will continue
for longer, I'm sure). However, we have a need for an OOP system,
and we will be making a choice for 8.4. This does not mean you can't
continue to use your preferred system. There may be some conflicts
if you use new features (like megawidgets), but I think on the whole
the community will greatly benefit from these changes.

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

* BTW, "oosystem" is just a name placeholder...

Don Porter

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> Just to make a few things clear where the lines seem to have blurred...

Just when I had my article full of questions ready to post...

> The core team decided that it was time for an OOP system in the core
> distribution, and to put it in with Tcl8.4. Whatever the choice is,
> it will be included in the distribution, but to get it you will have
> to do 'package require oosystem*', and it will have a separate dll.
> This is part of expanding Tcl's reach by modularization (without
> kernel bloat). For example, the 'thread' extension will be part of
> the Tcl8.4 distribution as well.

OK, so the object system and the thread extension will both be
packages written in C. The packages Tk, registry, and dde are
also packages written in C, but they are distributed differently.
Tk comes in a separate tarball, but dde and registry come contained
within the Tcl tarball, with their source code files intermingled
with those of the Tcl library. Which pattern will the new packages
follow, or will they start yet another variation?

It seems to me that you want to distribute packages written in C
as part of the "standard library", so you might as well bite the
bullet, figure out the right way to do that, and lift the restriction
that says only packages written in Tcl can be part of tcllib.

Of course, rather than any of these schemes for distributing more
and more packages with (the usual) Tcl distribution, I think I'd rather
see an effort to get a system like Perl's CPAN established which makes
it easy to find *any* package which may be needed. That would benefit
all package authors, not just those lucky enough to have their efforts
blessed and adopted by the core team.

BTW, which of the files tcl8.3.0.tar.gz, tk8.3.0.tar.gx, or tcl830.exe
is considered "the core distribution". And what parts of them are
considered to be "the core"?

--
| Don Porter, D.Sc. Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
|______________________________________________________________________|

Tom Poindexter

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
In article <38FE0051...@scriptics.com>,
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:

>take part in these discussions, as we are reading every line. This
>is everyone's time to shape the future of Tcl.

count me as another ouster-vote for [incr Tcl], for the reasons
pretty much hashed out here already.

--
Tom Poindexter
tpoi...@nyx.net
http://www.nyx.net/~tpoindex/

Mo

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs wrote:
>
> Just to make a few things clear where the lines seem to have blurred...
>
> The core team decided that it was time for an OOP system in the core
> distribution, and to put it in with Tcl8.4. Whatever the choice is,
> it will be included in the distribution, but to get it you will have
> to do 'package require oosystem*', and it will have a separate dll.
> This is part of expanding Tcl's reach by modularization (without
> kernel bloat). For example, the 'thread' extension will be part of
> the Tcl8.4 distribution as well.
>
> The reasons behind the need of an OOP system were for use in a
> megawidget system, and perhaps parts of tcllib. That means if you
> were to use these, they would implicitly require the OOP extension.
>
> [incr Tcl] is recognized as the most popular, and likely most
> robust OOP system for Tcl currently. However, some people are
> voicing their opinions against it as a choice (see the CLOS, or
> slots-based, vs C++/class-based discussions). I invite everyone to
> take part in these discussions, as we are reading every line. This
> is everyone's time to shape the future of Tcl.
>
> The core team realizes that any choice is going to make some people
> unhappy (OO argument have been around a long time, and will continue
> for longer, I'm sure). However, we have a need for an OOP system,
> and we will be making a choice for 8.4. This does not mean you can't
> continue to use your preferred system. There may be some conflicts
> if you use new features (like megawidgets), but I think on the whole
> the community will greatly benefit from these changes.
>
> --
> Jeffrey Hobbs The Tcl Guy
> jeffrey.hobbs at scriptics.com Scriptics Corp.
>
> * BTW, "oosystem" is just a name placeholder...


We need megawidget support, we need OO, it seems like the only
logical approach is to use Itcl. Why reinvent the whell when
Itcl already exists?

Mo Dejong
Red Hat Inc.

dhag...@millibits.com

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Accolades to the core team on this decision. I think it will
significantly improve Tcl's image in view of the "competing"
scripting languages such as Python and JavaScript.

I would like to put forth my vote for [incr Tcl] as well,
for the following reasons:

- While I can appreciate the elegance and simplicity of CLOS-
type OO systems (having written a bunch of code with CLOS in
grad school), it is readily apparent that *very* few
students are being trained to think/code in this fashion
outside CS departments. I think it would be shortsighted to
adopt an OO system only understood by a small number of highly
motivated and intelligent grad students.

- The corrolary to the above is that the majority of students
and programmers are learning OO programming the C++ and Java
way -- keywords/constructs such as class, private, protected,
etc. are well-taught and (presumably) well understood. TclOO,
being a pragmatic sort of language, would do well to adopt
such conventions.

- I think we stand a pretty good chance at mapping [incr Tcl]'s
constructs into the TclJava/Jacl system. I haven't thought very
hard about this yet but it seems very feasable. I dunno about
a 100%-pure-java implementation of incr, though...

- There are already several books out there about incr and
McLennan has an excellent training program.

- People are already building large, real-world, commercial projects
with it.

-=- D. J.

In article <38FE0051...@scriptics.com>,
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:

> [incr Tcl] is recognized as the most popular, and likely most
> robust OOP system for Tcl currently. However, some people are
> voicing their opinions against it as a choice (see the CLOS, or
> slots-based, vs C++/class-based discussions). I invite everyone to
> take part in these discussions, as we are reading every line. This
> is everyone's time to shape the future of Tcl.


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

Jeffrey Hobbs

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Mo wrote:
>
> Jeffrey Hobbs wrote:
> >
> > Just to make a few things clear where the lines seem to have blurred...

> We need megawidget support, we need OO, it seems like the only


> logical approach is to use Itcl. Why reinvent the whell when
> Itcl already exists?

Itcl may be the way to go, I said nothing that excludes it from
consideration. Now is the time for everyone to consider the issue.
For some this is revisiting, for others this is fresh. The important
point is that the discussion is made directly before the decision,
so we can point to this series of threads as the reasoning for our
choice. Therefore, those who think Itcl is the way to go should
continue to make their voices heard. Those who really are for another
system need to make clear points in favor of that system now.

Jeff David

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

> [incr Tcl] is recognized as the most popular, and likely most
> robust OOP system for Tcl currently. However, some people are
> voicing their opinions against it as a choice (see the CLOS, or
> slots-based, vs C++/class-based discussions). I invite everyone to
> take part in these discussions, as we are reading every line. This
> is everyone's time to shape the future of Tcl.
>

Put me down for [incr Tcl] as well for all the reasons others
have cited. To be honest, if you included anything else, I'd
ignore it and "package require Itcl" anyway. At this point,
my projects can't live without it and changing to another OOP
system is out of the question.

Jeff David

Frank Pilhofer

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
>
> I invite everyone to
> take part in these discussions, as we are reading every line. This
> is everyone's time to shape the future of Tcl.
>

I second the inclusion of [incr Tcl]. It's proven and mature.

Two things I'd like to see in an included version of [incr Tcl] is vir-
tual inheritance (currently, it's possible to do multiple inheritance,
but not "diamond" inheritance), and reference-counted objects, so that
objects are deleted when the last reference is lost. (For backwards com-
patibility, delete object could be redefined to do nothing.) The Tcl pro-
grammer doesn't need to clean up variables, so it should be the same for
objects.

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 ----+

Don Porter

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> Itcl may be the way to go, I said nothing that excludes it from
> consideration. Now is the time for everyone to consider the issue.
> For some this is revisiting, for others this is fresh. The important
> point is that the discussion is made directly before the decision,
> so we can point to this series of threads as the reasoning for our
> choice. Therefore, those who think Itcl is the way to go should
> continue to make their voices heard. Those who really are for another
> system need to make clear points in favor of that system now.

I'm very pleased to see the Tcl core team soliciting the opinions of
a wide audience of Tcl users before they make a major change to the
core (distribution). It seems to me there are two questions here
though.

1. Should the Tcl core (distribution) include (a package which provides)
commands which provide support for object oriented programming?

2. If so, should [incr Tcl] be that package, or something else?

I'm very pleased to see an invitation to discuss point 2, but it
seems the decision on point 1 has blown by without any public
discussion at all.

Lots of "big names" whose opinions I respect have posted declarations
that it is an obviously "good thing" that the Tcl core (distribution)
should support OOP itself, rather than leaving that to other packages
to provide. I guess I'm slow, but the case is not as obvious to me.
Can someone take the time to make the case for point 1, being as
explicit as possible?

What benefits will including an OOP package in the core distribution
provide over the status quo? Please be as explicit as possible.
I'd prefer a focus on technical arguments over public relations as
well. What will you be able to do when the core distribution includes
OOP support that you can't do (as easily) now?

Posting from Missouri, I guess... (ya gotta show me)

Mark Hecht

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Maybe we need a bicycle wheel instead of a bulldozer wheel.
(Or vice versa)

Re-inventing the wheel is a waste of time, but re-implementing
the wheel might not be.

Sorry if I come off as a wise guy, but this particular cliche is
starting to bug me :-)

...mark


Mo wrote:

> ...
> We need megawidget support, we need OO, it seems like the only
> logical approach is to use Itcl. Why reinvent the whell when
> Itcl already exists?

> ...


Bob Techentin

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Jeffrey Hobbs wrote:
>
> The core team decided that it was time for an OOP system
> in the core distribution ...

Whoopie!

> ... and we will be making a choice for 8.4.

Can't be that far off. We'll have to choose an existing OO system. I
see about a dozen listed on
http://dev.scriptics.com/resource/software/extensions/objects/

Being a pragmatic sort of fella, I automatically discount version zero
software, packages listed as "author unkown", and commercial packages.
That leaves Itcl, ClassyTcl, Framesets, jTcl, stooop, Tea, and TOS.

My immediate bias (might as well admit it) is towards Itcl. But it
might be useful to enumerate features that we would like in a Tcl core
OO system. That could help us determine the best system for inclusion
in the core distribution. I would nominate these features:

* objects with methods and attributes

* classes

* inheritance and polymorphism

* static and instance methods and attributes

* interfaces (abstract types and separating class definition from
implementation)

* introspection on everything

* interface to C/C++/Java procedures and objects

* Tcl_Obj integration

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

schwa...@my-deja.com

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
In article <38FE0051...@scriptics.com>,

Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> Just to make a few things clear where the lines seem to have
blurred...
>
> The core team decided that it was time for an OOP system in the core
> distribution, and to put it in with Tcl8.4. Whatever the choice is,
> it will be included in the distribution, but to get it you will have
> to do 'package require oosystem*', and it will have a separate dll.
> This is part of expanding Tcl's reach by modularization (without
> kernel bloat). For example, the 'thread' extension will be part of
> the Tcl8.4 distribution as well.
>
> The reasons behind the need of an OOP system were for use in a
> megawidget system, and perhaps parts of tcllib. That means if you
> were to use these, they would implicitly require the OOP extension.
>
> [incr Tcl] is recognized as the most popular, and likely most
> robust OOP system for Tcl currently. However, some people are
> voicing their opinions against it as a choice (see the CLOS, or
> slots-based, vs C++/class-based discussions). I invite everyone to

> take part in these discussions, as we are reading every line. This
> is everyone's time to shape the future of Tcl.
>
> The core team realizes that any choice is going to make some people
> unhappy (OO argument have been around a long time, and will continue
> for longer, I'm sure). However, we have a need for an OOP system,
> and we will be making a choice for 8.4. This does not mean you can't
> continue to use your preferred system. There may be some conflicts
> if you use new features (like megawidgets), but I think on the whole
> the community will greatly benefit from these changes.
>
> --
> Jeffrey Hobbs The Tcl Guy
> jeffrey.hobbs at scriptics.com Scriptics Corp.
>
> * BTW, "oosystem" is just a name placeholder...
>

Itcl might not be the perfect solution, but I think it is the "best"
solution. Even if you were to go ahead and develop a specific OO system
for the Tcl core, who says that it will actually turn out to be better;
I am not knocking anyones programming skills, it's just a fact that it
would be hard to write the "perfect" OO system.

I think Itcl would solve 2 tasks (although similar in nature) at once:
component building and mega-widget support.

--brett

David Gravereaux

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Put me down for Itcl as well.

I don't know the exact specifics, but when Itcl went from 2.2 to 3.0 as a
dynamic extension when the core went to 8.0, I think there were namespace
implementation differences in the core that never got resolved and I think left
a few bugs in Itcl. I think it has to do with the ability to bypass the class
structure and look directly at a private variable knowing namespace trail...
something like that.. I forget. I'm sure Chad Smith has some thoughts on
this.

Just bringing up the idea that the core might need a little freshening to mate
with Itcl better.
--
* David Gravereaux *
Tomahawk Software Group

If knowledge is power, how come the more I learn, the more I realize how much I don't know?
That isn't very empowering.

James Ingham

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

> Just to make a few things clear where the lines seem to have blurred...
>
> The core team decided that it was time for an OOP system in the core
> distribution, and to put it in with Tcl8.4. Whatever the choice is,
> it will be included in the distribution, but to get it you will have
> to do 'package require oosystem*', and it will have a separate dll.
> This is part of expanding Tcl's reach by modularization (without
> kernel bloat). For example, the 'thread' extension will be part of
> the Tcl8.4 distribution as well.
>

This is a great choice! I will also put in my voice for Itcl.

First reason is a pragmatic, but still powerful one: If Itcl is a part
of the core distribution, then I can leave off including it in the
software I use, and just rely on the standard Tcl. If you include
anything else, I am also going to ignore it and use Itcl, since it is
VERY unlikely that you are going to come out with anything so
compelling that I will be moved to rewrite 30,000 lines of Itcl code
to use it. I understand that this is not a "pure CS" reason, but
OTOH, if we were governed by pure CS arguments there would still be
lots of people willing to pay us to program in LISP...

I also want to agree with George and many of the other discussions on
this list, C++/Java style static OO is much more suitable for
framework construction, and better known...

Just on a personal note, it seems worth saying at least to me, that
the technical merits of another solution would have to not just equal,
but significantly outweigh, those of Itcl before I would approve it,
just on the basis of Michael dedicated and excellent work, and his
long standing advocacy & enthusiasm for Tcl.

This might seem a side note, inappropriate to a serious debate on the
weighty matters. But remember that you are not running a debating
society here, you are trying to foster an open source community. As
such you should encourage the efforts of members of that community -
especially when it is as easy & profitable to do so as it is in
Michael's case. So the fact that you are arguing theories, with one
excellent piece of work that has been sustained for years, and no
viable competitor, seems a bit odd & counterproductive to me, I must
admit...

Jim

--
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jin...@cygnus.com
Cygnus Solutions, a Red Hat Company

Jeffrey Hobbs

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to James Ingham
James Ingham wrote:
> This might seem a side note, inappropriate to a serious debate on the
> weighty matters. But remember that you are not running a debating
> society here, you are trying to foster an open source community. As
> such you should encourage the efforts of members of that community -
> especially when it is as easy & profitable to do so as it is in
> Michael's case. So the fact that you are arguing theories, with one
> excellent piece of work that has been sustained for years, and no
> viable competitor, seems a bit odd & counterproductive to me, I must
> admit...

Jim, I think it more odd that you would find the need for discussion
odd based on the number and range of posts on the subject. I think
only those in the community for a long time (such as yourself) will
see it as odd, having heard it before. However, it was very clear
at Tcl/2K that the community wanted to see more open discussion on
the matter. For most, it doesn't matter if this has come up before,
because before was years ago and truly most people on this group are
not 5+ year users.

Think of the alternative - a decision is made without community
discussion, only to leave others wondering without having heard
the crowd. Do you not wonder what 8.0 may have looked like if that
design discussion was more open? (we would potentially not even
be having this discussion...)

This is all anything but counterproductive (and I suppose we might
point out to the mostly unaware audience that you used to work for
Michael McLennan, so we can add more salt to your salty words :^) ),
and it isn't a popularity contest. This is a public design decision,
and the community should be prepared for more of such to come. In
that way we foster an open community. We all know that I could have
chosen to half-ass an OO system in Tcl in a day to use for things
like the megawidget system and tcllib and say "you can always still
add in your favorite OO extension", but I think we'll all be thankful
in the end that I had at least enough sense to not do that.

David Cuthbert

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Jeffrey Hobbs wrote:
> However, we have a need for an OOP system,
> and we will be making a choice for 8.4.

If I haven't already worn out my $0.02 :-), I don't care what is chosen for
Tcl 8.4 as long as I don't have to rewrite (much) my Itcl code, it behaves
the same, and performance doesn't noticably suffer. If I have to run my
code through a sed script, sure, no problem. But if I have to sit down and
rethink it into a new paradigm, forget it.

This is probably the least philosophical argument in the bunch, but it's
what will affect me the most.
--
David Cuthbert
da...@kanga.org

Don Porter

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
David Cuthbert <da...@kanga.org> wrote:
> If I haven't already worn out my $0.02 :-), I don't care what is chosen for
> Tcl 8.4 as long as I don't have to rewrite (much) my Itcl code, it behaves
> the same, and performance doesn't noticably suffer.

Would you mind adding another penny?

Why do you think you would have to rewrite anything? Presumably you
are currently able to separately download, build, and install Itcl.
Your scripts are able to [package require Itcl] and then make use
of the commands provided by Itcl.

How would the installation of another package which provides another
set of OOP-supporting commands influence the way your apps use Itcl?
Why can't you just keep doing exactly what you are doing now?

On the other hand, if you're effectively using Itcl now, what
difference would it make if it were distributed with the Tcl core?

What are the real gains and losses at stake?

David Cuthbert

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Don Porter wrote:
[Good arguments asking why I wouldn't be able to use Itcl later on]

> What are the real gains and losses at stake?

1. Keeping everything up-to-date. We've already seen what happens with
numerous extensions when Tcl gets updated and the extension gets left behind
(TclX, Tcl++, and even Itcl 3.0 when Tcl 8.1 came out). For every extension
I use that isn't in the core, I have to wait that much longer to update my
Tcl version (if I want to continue using those extensions).

2. Support. Because it is an extension, getting support for our build
environment is very expensive. Presumably, if Tcl 8.4 included [incr Tcl]
or a compatible alternate, getting this support would be easier. (Or is
this a pipe dream of mine?)

3. Ease of adoption. If everyone has Itcl, there's less reluctance to try
out an extension that relies upon it. (One of the first queries I got when
I announced the Telnet client was if I could rewrite it in plain Tcl instead
of Itcl.)

4. Ease of installation. I hate it when I download something and try to
compile/install it, only to have the installer complain that I don't have
libfoo.so.3.1.dll installed. Fewer things to download and maintain means
that I can be lazier. (Seriously!)

None of these arguments implies that [incr Tcl] -- or even a compatible
alternate -- be adopted, but they do argue for having an OO system in the
core. I'd prefer [incr Tcl] or a compatible alternative because:

5. Ease of transition. The less I have to rewrite, the faster I can transit
to the brand-spankin' new Tcl 8.4, and the fewer bugs I introduce in the
process.


Actually, looking back at this list, it's all motivated by laziness. But
laziness is a great motivator; otherwise, I'd eagerly write all my code in
assembly (C? Tcl? Scripts? Bah, that's for the lazy ilk!).
--
David Cuthbert
da...@kanga.org

George A. Howlett

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

> Jim, I think it more odd that you would find the need for discussion
> odd based on the number and range of posts on the subject. I think
> only those in the community for a long time (such as yourself) will
> see it as odd, having heard it before. However, it was very clear
> at Tcl/2K that the community wanted to see more open discussion on
> the matter. For most, it doesn't matter if this has come up before,
> because before was years ago and truly most people on this group are
> not 5+ year users.

It's odd because it strikes most people as a no-brainer. [incr Tcl]
is listed on your own website as the most popular extension. It's
robust and stable. It's been used in mission critical projects like
the Mars Pathfinder. There have been two books written about it.
There's nothing even close to compare it with.

It's odd because this is a old issue. Even if you believe that most
people haven't heard it before, it still doesn't add any merit.

It's odd because if Scriptics is ever to adopt any package, there's no
better candidate than [incr Tcl].


> This is all anything but counterproductive (and I suppose we might
> point out to the mostly unaware audience that you used to work for
> Michael McLennan, so we can add more salt to your salty words :^) ),
> and it isn't a popularity contest.

No, Jim has never worked for Michael McLennan. Yes, he shortly worked
with Michael at Bell Labs. Yes, Jim went to work for John Ousterhout
at Sun Labs. And yes, Michael and I work for the same company.

All of this is irrelevant to the merits of the points Jim raises
(unless your argument is "guilt by association").

> This is a public design decision,
> and the community should be prepared for more of such to come. In
> that way we foster an open community. We all know that I could have
> chosen to half-ass an OO system in Tcl in a day to use for things
> like the megawidget system and tcllib and say "you can always still
> add in your favorite OO extension", but I think we'll all be thankful
> in the end that I had at least enough sense to not do that.

I think we all appreciate the job you've done as Tcl Ambassador. But,
I can understand being a little defensive. There are strong sentiments
on this issue, maybe because it's been neglected for so long.

--gah

ma...@usai.asiainfo.com

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Don Porter <d...@clover.cam.nist.gov> wrote:
> What benefits will including an OOP package in the core distribution
> provide over the status quo? Please be as explicit as possible.

Because the next time I sit through a meeting with people objecting
to Tcl because "it doesn't support OO" I'm going to stick a spoon
down my throat and retch all over the table. Is that explicit enough?

> I'd prefer a focus on technical arguments over public relations as
> well.

Oh. Then because I want a good ubiquitous component model, for both
externally and internally written components.

Rgds,
Mark.

Disclaimer: company policy neither santions nor condones any
activity mentioned in this post.

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

Johannes Schacht

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

> [incr Tcl] is recognized as the most popular, and likely most

> robust OOP system for Tcl currently. However, ...

However it is slow. At least from what I measure and from what
I judge based on these figures. Object creation takes pretty long.
Look at these numbers:

RawItclClass 261 microseconds per iteration
RawDerived 470 microseconds per iteration
RawDerived2 711 microseconds per iteration
methodCall 20 microseconds per iteration
pwdCall 10 microseconds per iteration

Object creation gets in the range of a millisecond. And each
object eats up 0.5 to 1 KB. These times are killing you, when
you deal with any bigger number objects outside (in an non
GUI app).

I used the script below on a NT-Box with Intel 333 MHZ, 128MB Ram
and protclsh82.

####################################################

package require Itcl
namespace import ::itcl::*

#--- Define some class
class RawItclClass {
public variable v1
public variable v2
public variable v3

constructor {args} {
eval configure $args
set v2 "v2 value"
set v3 "v3 value"
}
public method setV3 {val} {
set v3 $val
}
}

#--- Derive a class
class RawDerived {
inherit RawItclClass

constructor {args} {
eval configure $args
chain
} {
}
}

#--- Derive even further
class RawDerived2 {
inherit RawDerived

constructor {args} {
eval configure $args
chain
} {
}
}

#--- Get creation times for objects
foreach cc "RawItclClass RawDerived RawDerived2" {
puts [format "%-20s %s" $cc [time "$cc #auto" 1000]]
}

#--- Get command execution times as comparison
RawDerived d
puts [format "%-20s %s" methodCall [time "d setV3 33" 1000]]
puts [format "%-20s %s" pwdCall [time "pwd" 1000]]

ma...@usai.asiainfo.com

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
BTW, for those concerned that I may be just an uncritical stooge
of the vast right wing object conspiracy:

I would like to point out that, as far as I know, I was the first
person to note that the acronym for "Pure Object Oriented Programming"
is "POOP", and that this should sound some cautionary note
against excessive object oriented hubris.

I sent a letter noting this to JOOP (Journal of OO Programming)
in order to establish my priority, but for some reason they didn't
seem to think it worth printing.

Best regards to all posters,
Mark

ma...@usai.asiainfo.com

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> The important
> point is that the discussion is made directly before the decision,
> so we can point to this series of threads as the reasoning for our
> choice.

Jeffrey,

It looks like most people have weighed in with whatever points,
opinions, and votes they are going to. It's been good so far,
and a lot of good points have been made by a lot of people.
If it goes on much longer, it will devolve into it repetetive
arguments, personal issues, etc.

Can you wrap this up for us? Tally the votes, compare the
different packages that have been proposed, and present the
results?

Thanks,
Mark.

ma...@usai.asiainfo.com

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Johannes Schacht <Johannes...@t-online.de> wrote:
> Jeffrey Hobbs wrote:

>> [incr Tcl] is recognized as the most popular, and likely most
>> robust OOP system for Tcl currently. However, ...

> However it is slow. At least from what I measure and from what
> I judge based on these figures. Object creation takes pretty long.

But you have to consider that, outside of a performance
benchmark test, you don't randomly create nested inheritance
structures without some particular need. You call
"eval configure $args", etc.

Nobody argues that itcl is faster than a simple inline
script (well, that is if an inline script were compiled
before execution).

What you need to do is figure out what you are modelling
(abstract data type storage, widget configuration data,
or whatever), and test the various solutions to that
model.

This shows one of itcl's philosophical strenths,
which it inherited from C++. It is not a "pure" object
solution, so when objects don't fit your problem, you
don't need to use them.

Rgds,

Paul Duffin

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Jeffrey Hobbs wrote:
>
> Just to make a few things clear where the lines seem to have blurred...
>
> The core team decided that it was time for an OOP system in the core
> distribution, and to put it in with Tcl8.4. Whatever the choice is,
> it will be included in the distribution, but to get it you will have
> to do 'package require oosystem*', and it will have a separate dll.
> This is part of expanding Tcl's reach by modularization (without
> kernel bloat). For example, the 'thread' extension will be part of
> the Tcl8.4 distribution as well.
>
> The reasons behind the need of an OOP system were for use in a
> megawidget system, and perhaps parts of tcllib. That means if you
> were to use these, they would implicitly require the OOP extension.
>

I think that the hooks necessary for doing megawidget support should not
require using OOP. The main reason being that there are a lot of widgets
sets out there which could be improved by some basic megawidget stuff,
e.g. focus management, but which for whatever reason should not have to
be rewritten in whatever OOP extension is used.

As for using it as part of the tcllib, this may be overkill for some of
the data types. Data types such as vectors, structures etc do not actually
need to be [incr Tcl] classes. There is no valid reason to inherit from
them, they are building blocks for use in other classes. For performance
they should be hand coded in C with consistent rules etc.

> [incr Tcl] is recognized as the most popular, and likely most

> robust OOP system for Tcl currently. However, some people are
> voicing their opinions against it as a choice (see the CLOS, or
> slots-based, vs C++/class-based discussions). I invite everyone to
> take part in these discussions, as we are reading every line. This
> is everyone's time to shape the future of Tcl.
>

While [incr Tcl] is certainly the best choice, it still has a few problems.
Performance of [incr Widgets] is a big one for me, this has a lot to do with
the option propagation and a lot to do with the actual hierarchy of widgets
as opposed to [incr Tcl] itself. But there are some problems with
[incr Tcl]'s performance as well as resource usage. e.g. Creation of an object
which is at the bottom of a deep inheritance stack takes a long time to
create simply because of the number of mallocs it has to do because it does
one malloc for each class in the stack.

Another things which [incr Tcl] needs is for its objects to be automatically
cleaned up when the reference to it goes away, without this there will be an
awful lot of memory leaks to track down.

Feather (source available RSN) can solve a lot of these problems but it also
adds some more requirements. e.g. the ability to add an interface to an
[incr Tcl] class so you can create [incr Tcl] classes which can be treated
like containers etc.

Jeff David

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

> However, it was very clear
> at Tcl/2K that the community wanted to see more open discussion on
> the matter.
>

Oh really? Were we at the same conference? The prevailing sentiment
*I* heard after the talk about yet another OOP system was "Why? We
already have [incr Tcl] and it is great." But then, you and I don't
socialize with the same people at the Tcl conferences.

> Think of the alternative - a decision is made without community
> discussion, only to leave others wondering without having heard
> the crowd. Do you not wonder what 8.0 may have looked like if that
> design discussion was more open? (we would potentially not even
> be having this discussion...)
>

I don't have a problem with a community discussion. What I have
a problem with is your apparent prejudice towards a slots-based
OOP system when the vast majority of the community CLEARLY uses
and LIKES the established, proven, stable, class-based [incr Tcl]
solution. Does this mean [incr Tcl] could not use improvement?
No. But it means that it is certainly the base to work from.

I also find it incredible that Scriptics, with its highly limited
core resources, could be seriously considering anything BUT [incr Tcl]
since that would also be the cheapest and quickest solution. You
have other things to work on. I certainly didn't see "Develop
a new OOP system" get even ONE Oustervote.

This should be a no-brainer. I find your recalcitrance puzzling.

Jeff David

laurent....@cgi.ca

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
On 20 Apr, David Cuthbert wrote:
>
> Actually, looking back at this list, it's all motivated by laziness. But
> laziness is a great motivator; otherwise, I'd eagerly write all my code in
> assembly (C? Tcl? Scripts? Bah, that's for the lazy ilk!).

:-) I actually think I spend more time coding to sustain my innate laziness
than for any other reason.

L

--
Laurent Duperval "Montreal winters are an intelligence test,
mailto:laurent....@cgi.ca and we who are here have failed it."
-Doug Camilli
Penguin Power! ***Nothing I say reflects the views of my employer***


Bob Techentin

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
David Cuthbert wrote:
>
> Tcl? Scripts? Bah, that's for the lazy ilk!

That gets my vote for quote of the week.

Bob Techentin

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Johannes Schacht wrote:

>
> Jeffrey Hobbs wrote:
>
> > [incr Tcl] is recognized as the most popular, and likely most
> > robust OOP system for Tcl currently. However, ...
>
> However it is slow. At least from what I measure and from what
> I judge based on these figures. Object creation takes pretty long.
> Look at these numbers:
>
> RawItclClass 261 microseconds per iteration
> RawDerived 470 microseconds per iteration
> RawDerived2 711 microseconds per iteration
> methodCall 20 microseconds per iteration
> pwdCall 10 microseconds per iteration
>

I don't think it is particularly fair to compare Itcl object creation
with calling the built in [pwd] command.

You would elect to use an OO system when you have complex problems to
solve and you want to write less code. It would be more reasonable to
compare Itcl's speed with a Tcl-only solution for creating object
abstractions. I've created a "fake" class structure patterned after the
stack structure defined in tcllib, which is about as thorough a Tcl-only
implementation as I've seen all week.

These are the timings I get on an HP workstation - and look at now much
more code you use with the Tcl-only solution!!

RawItclClass 404 microseconds per iteration
methodCall 40 microseconds per iteration
fakeClass 1604 microseconds per iteration
fakeMethodCall 332 microseconds per iteration

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

package require Itcl
namespace import ::itcl::*

#--- Define some class
class RawItclClass {
public variable v1
public variable v2
public variable v3

constructor {args} {
eval configure $args
set v2 "v2 value"
set v3 "v3 value"
}
public method setV3 {val} {
set v3 $val
}
}

#--- Get creation times for objects

puts [format "%-20s %40s" RawItclClass [time "RawItclClass #auto" 1000]]

#--- Get command execution times as comparison

RawItclClass d
puts [format "%-20s %40s" methodCall [time "d setV3 33" 1000]]


#--- Fake object creation using namespaces and
# global variables
namespace eval fakeClass {

variable v1
variable v2
variable v3
variable fakeObjs

variable counter 0

variable commands [list \
"setV3" \
]
namespace export fakeClass
}

# fake constructor for our fake class
proc fakeClass::fakeClass { {name ""} } {
variable v1
variable v2
variable v3
variable fakeObjs
variable counter

if { [llength [info level 0]] == 1 } {
incr counter
set name "fake${counter}"
}
if { ![string equal [info commands ::$name] ""] } {
error "command \"$name\" already exists, unable to create fakeClass"
}

set fakeObjs($name) [list ]
set v1($name) [list ]
set v2($name) "v2 value"
set v3($name) "v3 value"

# Create the command to manipulate the stack
interp alias {} ::$name {} ::fakeClass::fakeClassProc $name

return $name
}

proc ::fakeClass::fakeClassProc {name {cmd ""} args} {
# Do minimal args checks here
if { [llength [info level 0]] == 2 } {
error "wrong # args: should be \"$name option ?arg arg ...?\""
}

# Split the args into command and args components
if { [llength [info commands ::fakeClass::_$cmd]] == 0 } {
variable commands
set optlist [join $commands ", "]
set optlist [linsert $optlist "end-1" "or"]
error "bad option \"$cmd\": must be $optlist"
}
eval [list ::fakeClass::_$cmd $name] $args
}

proc ::fakeClass::_setV3 {name value} {
set ::fakeClass::v3($name) $value
}


#--- Get creation times for fake objects
namespace import fakeClass::*
puts [format "%-20s %40s" fakeClass [time "fakeClass" 1000]]


#--- Get command execution times as comparison

fakeClass f
puts [format "%-20s %40s" fakeMethodCall [time "f setV3 33" 1000]]

Johannes Schacht

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
ma...@usai.asiainfo.com wrote:
>
> Johannes Schacht <Johannes...@t-online.de> wrote:
>
> > However [incr Tcl] is slow. At least from what I measure and from what

> > I judge based on these figures. Object creation takes pretty long.
>
> But you have to consider that, outside of a performance
> benchmark test, you don't randomly create nested inheritance
> structures without some particular need. You call
> "eval configure $args", etc.
>
The application that I've built has grown to 100-200 classes,
with an inheritance depth of five levels or so. (It surprised me,
how large it got, but that's the size it ought to have).
No we experiencing a real performance problem and the only
solution seems to be to switch back to C++. What makes me
wonder is, that tcl is so fast and *using* iTcl classes is fast,
but object creation and deletion is so slow.

Regards, Johannes Schacht

Paul Duffin

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
ma...@usai.asiainfo.com wrote:
>
> Johannes Schacht <Johannes...@t-online.de> wrote:
> > Jeffrey Hobbs wrote:
>
> >> [incr Tcl] is recognized as the most popular, and likely most
> >> robust OOP system for Tcl currently. However, ...
>
> > However it is slow. At least from what I measure and from what

> > I judge based on these figures. Object creation takes pretty long.
>
> But you have to consider that, outside of a performance
> benchmark test, you don't randomly create nested inheritance
> structures without some particular need. You call
> "eval configure $args", etc.
>

Ok, but as a benchmark to test the creation times for an [incr Tcl] object
it seems very reasonable to me. In fact I would hazard a guess that an
inheritance tree 3 deep is actually quite shallow by some standards and
does not even have any multiple inheritance so you could say it is
unrealistic on that score.

[incr Tcl] is slower than it should be, there is a lot more that could be
done to [incr Tcl] to make it faster than it is without changing the
Tcl interface (much ;-)).

Don Porter

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
<ma...@usai.asiainfo.com> wrote:
> It looks like most people have weighed in with whatever points,
> opinions, and votes they are going to. It's been good so far,
> and a lot of good points have been made by a lot of people.
> If it goes on much longer, it will devolve into it repetetive

Whoa there, pardner! You may not intend this, but when I read
the above, I see:

"It looks like most people are agreeing with me, so let's end the
conversation now, so I can win."

Please give us slow folks in the back of the class a chance to
catch up. If these decisions truly are "no-brainers" then please
won't some people take the time to write a few paragraphs making
the case that new commands supporting OOP are a necessary
addition to the core distribution.

So far, I've seen a lot of "Hooray!" and very little argument.

> Can you wrap this up for us? Tally the votes, compare the
> different packages that have been proposed, and present the
> results?

I strongly object to the notion that this decision is one to
be made by popular vote. Popular desires are important and
should factor into the decision, but technical merit should
have at least equal consideration.

I may very well end up agreeing with everything you want in
the core distribution, but please make the case. Compare
the current Tcl distribution with the one you want, and tell
me what benefits the changes provide.

Chang LI

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

Paul Duffin wrote in message <38FEF2D7...@hursley.ibm.com>...

>
>I think that the hooks necessary for doing megawidget support should not
>require using OOP. The main reason being that there are a lot of widgets
>sets out there which could be improved by some basic megawidget stuff,
>e.g. focus management, but which for whatever reason should not have to
>be rewritten in whatever OOP extension is used.
>

Why use the OOP if it can not help on megawidget?

>As for using it as part of the tcllib, this may be overkill for some of
>the data types. Data types such as vectors, structures etc do not actually
>need to be [incr Tcl] classes. There is no valid reason to inherit from
>them, they are building blocks for use in other classes. For performance
>they should be hand coded in C with consistent rules etc.
>

If we use OOP with inheritance in a foundation library like tcllib,
I will avoid to use it. How do you extend the library? By inheritance?
You are forced to learn the structure of the library before you
use one component.

Chang

lvi...@cas.org

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

According to Don Porter <d...@cam.nist.gov>:
:How would the installation of another package which provides another

:set of OOP-supporting commands influence the way your apps use Itcl?
:Why can't you just keep doing exactly what you are doing now?

One thing that I have seen in supporting an environment where a number
of different extensions are used is that it takes a certain amount of time
before all extensions support a new release. One fear that was discussed
at least a bit around me was the fear that any fundamental changes
in the Tcl and Tk core has the potential for creating incompatibilities
in TclX, itcl, Tix, etc. Since original author support on these extensions
appears at times to be less due to 'real world' activities in the lives
of the authors, the more such incompatibilities are introduced, the
longer it might be until general use of the new version is possible.

--
<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.

Bob Techentin

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Don Porter wrote:
>
> What benefits will including an OOP package in the core distribution
> provide over the status quo? Please be as explicit as possible.
> I'd prefer a focus on technical arguments over public relations as
> well. What will you be able to do when the core distribution includes
> OOP support that you can't do (as easily) now?

Very good question, Don. Even my technical benefit is a sort of
political issue.

Although I own a license and use TclPro, I choose to build and deploy
applications from open source Tcl/Tk and extensions. To upgrade Tcl I
must fetch, configure, and build Tcl/Tk, IncrTcl, BLT and TclX. Even
though Tcl and Tk are separate tarballs, they are essentially the same
from a release/configure/make/install perspective. Each other extension
requires additional time and effort beyond that required by the core
Tcl/Tk. Some more than others, but they all require additional effort.

With an OO system included in the core distribution, I could build and
install Tcl/Tk/Incr and only two extensions. That saves me time and
effort.

Political reasons are good too. An officially blessed OO extension
would be a good thing for Tcl. Competing for mindshare, convincing
bosses, and bundling support are important issues that sometimes
transcend the coding issues.

Don Porter

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Don Porter wrote:
>> What are the real gains and losses at stake?

Thank you for your reply. I hope that others will also weigh in so I
can understand just what is to be accomplished by welding an object
system into the core distribution.

David Cuthbert <da...@kanga.org> wrote:
> 1. Keeping everything up-to-date. We've already seen what happens with
> numerous extensions when Tcl gets updated and the extension gets left behind
> (TclX, Tcl++, and even Itcl 3.0 when Tcl 8.1 came out). For every extension
> I use that isn't in the core, I have to wait that much longer to update my
> Tcl version (if I want to continue using those extensions).

This used to be a very big problem, because packages written in C had to
have releases which tracked the releases of Tcl.

This problem now has a solution: the stubs interface. Once a package
written in C is stub-enabled, there is no longer this lockstep
requirement on the releases. Stub-enabled foo 1.1 which happily loads
into Tcl 8.1 will continue to happily load into Tcl 8.4,....

I think that decoupling the releases of packages from releases of Tcl is
a very good thing. I would like to see Tk's releases decoupled from
Tcl's. Adding packages to the Tcl core distribution tends to couple the
release calendars, not decouple them.

> 2. Support. Because it is an extension, getting support for our build
> environment is very expensive. Presumably, if Tcl 8.4 included [incr Tcl]
> or a compatible alternate, getting this support would be easier. (Or is
> this a pipe dream of mine?)

I'm not sure I completely follow this. Probably because lots and lots
of issues get thrown into that word "support". Perhaps it means there's
someone you can ask for help when Itcl doesn't successfully build or
install on your platform. Perhaps it means someone is regularly
packaging the Itcl package for distribution, rather than providing only
CVS access to the latest versions.

I agree that including Itcl in the Tcl distribution probably means
improved support for Itcl. That's certainly a benefit to the users of
Itcl. But what's in it for the rest of the Tcl users? Can't improved
support for Itcl be provided by other means than placing it in the core
distribution? You could even have the same Tcl core team providing that
support, but offering Itcl as a separate download.

> 3. Ease of adoption. If everyone has Itcl, there's less reluctance to try
> out an extension that relies upon it. (One of the first queries I got when
> I announced the Telnet client was if I could rewrite it in plain Tcl instead
> of Itcl.)
>
> 4. Ease of installation. I hate it when I download something and try to
> compile/install it, only to have the installer complain that I don't have
> libfoo.so.3.1.dll installed. Fewer things to download and maintain means
> that I can be lazier. (Seriously!)

These are essentially the same point, first from the developer
perspective, and second from the end user perspective.

This is a benefit for developers who wish to distribute packages which
depend on Itcl. It shortens their instructions. Currently they have to
say: 1) Download and install Tcl 2) Download and install Itcl
3) Download and install my package. If Itcl is distributed with Tcl,
they can drop step 2.

But what about those developers who distribute packages which depend on,
say, BLT? This doesn't do a thing for them. Should we also weld BLT
into the core distribution? Where do we stop?

The fundamental problem is that it is a pain to find and install a
compatible collection of Tcl packages needed to support a particular Tcl
application. I'd rather have the efforts of the Tcl community channeled
toward solving that general problem instead of working around it by
adding more and more packages to the core distribution. Supplying the
workaround actually decreases the demand for the general solution and
delays it further.

> I'd prefer [incr Tcl] or a compatible alternative because:
> 5. Ease of transition. The less I have to rewrite, the faster I can transit
> to the brand-spankin' new Tcl 8.4, and the fewer bugs I introduce in the
> process.

Again, I fail to see why there's any transition required at all. No
matter what packages ship with the Tcl core distribution, so long as Tcl
8.4 maintains the backward compatibility it is supposed to, your
stub-enabled Itcl package will keep working and all your current uses of
Tcl+Itcl should continue working as before. It's possible there will be
performance differences, but the basic functioning should be
undisturbed.

Tom Krehbiel

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
I agree with others in this news group that [incr Tcl] should be the
starting point for the OO design. I say this for mostly pragmatic and
continuity reasons. With this said, I think that no feature or function
should be considered sacred. I think the key to success will be to have a
clearly defined transition plan and clearly defined set of goals. I am
willing to deal with major changes if I understand the goals and can plan
for them. My preference is to initially focus on a good OO language
interface and then to deal with speed issues. I know this could lead to
trouble but I think consensus on language design is the more important
issue.
$.02
Tom Krehbiel

Jeffrey Hobbs wrote:

> Just to make a few things clear where the lines seem to have blurred...
>
> The core team decided that it was time for an OOP system in the core
> distribution, and to put it in with Tcl8.4. Whatever the choice is,
> it will be included in the distribution, but to get it you will have
> to do 'package require oosystem*', and it will have a separate dll.
> This is part of expanding Tcl's reach by modularization (without
> kernel bloat). For example, the 'thread' extension will be part of
> the Tcl8.4 distribution as well.
>
> The reasons behind the need of an OOP system were for use in a
> megawidget system, and perhaps parts of tcllib. That means if you
> were to use these, they would implicitly require the OOP extension.
>

> [incr Tcl] is recognized as the most popular, and likely most

> robust OOP system for Tcl currently. However, some people are
> voicing their opinions against it as a choice (see the CLOS, or
> slots-based, vs C++/class-based discussions). I invite everyone to
> take part in these discussions, as we are reading every line. This
> is everyone's time to shape the future of Tcl.
>

> The core team realizes that any choice is going to make some people
> unhappy (OO argument have been around a long time, and will continue
> for longer, I'm sure). However, we have a need for an OOP system,
> and we will be making a choice for 8.4. This does not mean you can't
> continue to use your preferred system. There may be some conflicts
> if you use new features (like megawidgets), but I think on the whole
> the community will greatly benefit from these changes.
>

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

Chang LI

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

Jeffrey Hobbs wrote in message <38FE0051...@scriptics.com>...

>Just to make a few things clear where the lines seem to have blurred...
>
>The core team decided that it was time for an OOP system in the core
>distribution, and to put it in with Tcl8.4. Whatever the choice is,
>it will be included in the distribution, but to get it you will have
>to do 'package require oosystem*', and it will have a separate dll.
>This is part of expanding Tcl's reach by modularization (without
>kernel bloat). For example, the 'thread' extension will be part of
>the Tcl8.4 distribution as well.
>

So OOP is just a package of core.

>The reasons behind the need of an OOP system were for use in a
>megawidget system, and perhaps parts of tcllib. That means if you
>were to use these, they would implicitly require the OOP extension.
>

I strongly against to use inheritance for constructing a foundation library
such as tcllib. MFC is a well known unsuccessful example. It is difficult
to use because you need to know entire internal structure and the
definition of its parents.

For megawidget system, why could not we create a Tk widget
with Tcl scripts? Is inheritance of OOP needed in this case?
In this case I see more container relationship rather than inheritance
relationship.

>[incr Tcl] is recognized as the most popular, and likely most
>robust OOP system for Tcl currently. However, some people are
>voicing their opinions against it as a choice (see the CLOS, or
>slots-based, vs C++/class-based discussions). I invite everyone to
>take part in these discussions, as we are reading every line. This
>is everyone's time to shape the future of Tcl.
>

I think Tk is a kind of OOP. It may not belong to slots-based or
class-based. Unfortunately we can only define a Tk widget in the
C level. Is it possible to build a Tk like object with Tcl? The answer
should be yes.

There are lots of definition of OOP. Somebody said inheritance is
must be. But in the case of Tcl and Tk like OOP, I do not think so.
Without inheritance, the performance will be improved.
I prefer to the representation of itcl-like. Because class definition
represents the abstract data type which should be help to construct
large program. One purpose of use OOP is to build large softwre.
I do not know whether slots-based OOP will help you to build large
software project.

Chang LI


Denis Medvedev

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Don Porter wrote:
>
> Don Porter wrote:
> >> What are the real gains and losses at stake?
>
>
> These are essentially the same point, first from the developer
> perspective, and second from the end user perspective.
>
> This is a benefit for developers who wish to distribute packages which
> depend on Itcl. It shortens their instructions. Currently they have to
> say: 1) Download and install Tcl 2) Download and install Itcl
> 3) Download and install my package. If Itcl is distributed with Tcl,
> they can drop step 2.
>
> But what about those developers who distribute packages which depend on,
> say, BLT? This doesn't do a thing for them. Should we also weld BLT
> into the core distribution? Where do we stop?
Nowhere! My opinion is that TCL core distribution should include ALL
widely_used packages. User should have an option
to download a blt-stripped or itcl-stripped version of tcl.
But main core should contain ALL of them, license permitting.
It was a real pain to figure out how to add packages. Much better to
force user to strip if he want, not to add.

Tom Krehbiel

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Bob,
Why in the world are you building and deploying your applications from open
source Tcl/Tk and extensions if you own and do development with TclPro? The
TclPro core and extensions are all free including IncrTcl,TclX,Expect,etc.
-tjk

Bob Techentin wrote:

Don Porter

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Don Porter <d...@clover.cam.nist.gov> wrote:
>> What benefits will including an OOP package in the core distribution
>> provide over the status quo? Please be as explicit as possible.

<ma...@usai.asiainfo.com> wrote:
> Because the next time I sit through a meeting with people objecting
> to Tcl because "it doesn't support OO" I'm going to stick a spoon
> down my throat and retch all over the table. Is that explicit enough?

:) I agree that the more "social" reasons are important, perhaps
even compelling, but for my own clarity of thinking I'd like to consider
them separately from the technical reasons.

When people claim that Tcl "doesn't support" OO, do they also complain
that Tcl doesn't support control structures? Fundamentally, Tcl is just
a parser, a set of substitution rules, and a way to register and
dispatch commands which actually do all the work. Tcl doesn't include
as part of the language definition a lot of things which are included in
other scripting languages. Tcl's different. Get over it.

Tcl's minimalism is part of the reason it can be successfully applied in
so many different contexts to do so many different things. You add the
features you need by loading packages which provide them.

The issue is how does one get the packages they need? Which packages
need to be distributed with the core distribution? What criteria should
be used to make that decision?

> Oh. Then because I want a good ubiquitous component model, for both
> externally and internally written components.

If the object-system-providing package is going to be a package, and not
part of the Tcl core (that is, the Tcl library, libtcl.so) itself, then
there can be no "internally written" components.

The desire to make Itcl the "ubiquitous component model" sounds to me
like a desire to forc^H^H^H strongly encourage all Tcl developers
interested in creating components to adopt the same object system you
chose to adopt.

When many authors build their components on top of the same object
system, they can more powerfully make use of one another's work. I
agree there are strong network effects here which should encourage
component authors to use existing object systems which are already
popular, rather than invent their own object system.

For that reason, any Tcl developer planning to write OO components,
should have a strong incentive to use Itcl unless they have some very
strong reason not to.

Why isn't that incentive sufficient? Why does the case for Itcl need to
be further strengthened by distributing it with Tcl? Is it simply a
matter of information? Are there significant numbers of Tcl newbies who
don't learn about the existence of Itcl until they've already taken the
misstep of creating their own object systems?

Thomas Andrews

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
In article <38FF092A...@chat.ru>, Denis Medvedev <m...@chat.ru> wrote:

>Don Porter wrote:
>>
>> Don Porter wrote:
>> >> What are the real gains and losses at stake?
>>
>>
>> These are essentially the same point, first from the developer
>> perspective, and second from the end user perspective.
>>
>> This is a benefit for developers who wish to distribute packages which
>> depend on Itcl. It shortens their instructions. Currently they have to
>> say: 1) Download and install Tcl 2) Download and install Itcl
>> 3) Download and install my package. If Itcl is distributed with Tcl,
>> they can drop step 2.
>>
>> But what about those developers who distribute packages which depend on,
>> say, BLT? This doesn't do a thing for them. Should we also weld BLT
>> into the core distribution? Where do we stop?
>Nowhere! My opinion is that TCL core distribution should include ALL
>widely_used packages.

Isn't that stretching the word "core" a bit?

--
Thomas Andrews tho...@best.com http://www.best.com/~thomaso/
"You have no idea what a poor opinion I have of myself,
and how little I deserve it." - W.S.Gilbert

Thomas Andrews

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
In article <8dnfs7$6e0$1...@bob.news.rcn.net>,

Don Porter <d...@cam.nist.gov> wrote:
>Don Porter <d...@clover.cam.nist.gov> wrote:
>>> What benefits will including an OOP package in the core distribution
>>> provide over the status quo? Please be as explicit as possible.
>
> <ma...@usai.asiainfo.com> wrote:
>> Because the next time I sit through a meeting with people objecting
>> to Tcl because "it doesn't support OO" I'm going to stick a spoon
>> down my throat and retch all over the table. Is that explicit enough?
>
>:) I agree that the more "social" reasons are important, perhaps
>even compelling, but for my own clarity of thinking I'd like to consider
>them separately from the technical reasons.
>
>When people claim that Tcl "doesn't support" OO, do they also complain
>that Tcl doesn't support control structures?

No, we don't, because the language supports a natural and simple way to implement
efficient control structures, and comes with some of the most basic control
structures built in.

I find myself constantly thinking in objects then having to "translate" those
ideas to Tcl, a painful exercise most of the time, especially when efficiency
is required.

If I had to decide whose version of "if { ... } then { ... }" to use
each time I used Tcl, I'd probably complain, especially if all of them
were inefficient. :-)

James Ingham

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

> James Ingham wrote:
> > This might seem a side note, inappropriate to a serious debate on the
> > weighty matters. But remember that you are not running a debating
> > society here, you are trying to foster an open source community. As
> > such you should encourage the efforts of members of that community -
> > especially when it is as easy & profitable to do so as it is in
> > Michael's case. So the fact that you are arguing theories, with one
> > excellent piece of work that has been sustained for years, and no
> > viable competitor, seems a bit odd & counterproductive to me, I must
> > admit...


>
> Jim, I think it more odd that you would find the need for discussion
> odd based on the number and range of posts on the subject. I think
> only those in the community for a long time (such as yourself) will

> see it as odd, having heard it before. However, it was very clear


> at Tcl/2K that the community wanted to see more open discussion on

> the matter. For most, it doesn't matter if this has come up before,
> because before was years ago and truly most people on this group are
> not 5+ year users.

BUT... these very issues HAVE been discussed for 5+ years in the Tcl
community. It is not like ANY new points are being raised here.
There is no way to determine whether a slots based approach is
"better" than a static approach, there really aren't metrics on any of
these spaces. The community has largely already voted, as Mark keeps
pointing out. I don't remember hearing any of the "Large project uses
Tcl and is successful" conference talks, success stories, etc, that
used any of the competing OO systems. And as Mark said, pretty much
ALL of them DID include Itcl, and many said they would not have been
able to do the job they did without it.

So given the history, raising the discussion again, rather than
accepting what is a pretty clear community consensus is just dissing
Michael's work again, for no very good reason.

>
> Think of the alternative - a decision is made without community
> discussion, only to leave others wondering without having heard
> the crowd. Do you not wonder what 8.0 may have looked like if that
> design discussion was more open? (we would potentially not even
> be having this discussion...)

Again, design discussions are good, we have just had this one to death
over the past many years.

>
> This is all anything but counterproductive (and I suppose we might
> point out to the mostly unaware audience that you used to work for
> Michael McLennan, so we can add more salt to your salty words :^) ),
> and it isn't a popularity contest.

That I worked for Michael is totally irrelevant (and as George pointed
out, I didn't).

However, a good part of the point of the note was that my fondness for
Michael, which is shared, by the way, by a very substantial portion of
the Tcl community, and is generated not only by what a nice fellow he
is, but by his VERY substantial contributions to the Tcl community
over many years, IS or at least should be a significant factor in any
such decision. Considering my relation to Michael some HIDDEN
factor in the note I wrote indicates you pretty much missed its point,
which was just the thing you state was hidden!

On to the content... Popularity contest? What did you ask for? An
Ouster vote... What is an Ouster vote? A popularity contest.

Of course it is based on technical merit. But be careful, in a
community effort, if someone has put forward a solution, and it is a
good solution, and they have supported it for years, sometimes in the
face of considerable - let's call it "neglect" to be polite - THAT
also is a factor. Why? Because if you set the example of ignoring
people's substantial contributions and dedication, you are not
fostering a community in which others will want to contribute.

This does not seem controversial to me, it seems like pretty plain
common sense. In fact, it seems to me a lesson that up till now
Scriptics has been taking more to heart than ever was done during the
Sun days where the practice of rewriting every piece of code that went
into the core, sometimes for good reasons, sometimes not, created a
lot of antagonism in the community which it would have been better to
have avoided...

> This is a public design decision,
> and the community should be prepared for more of such to come. In
> that way we foster an open community. We all know that I could have
> chosen to half-ass an OO system in Tcl in a day to use for things
> like the megawidget system and tcllib and say "you can always still
> add in your favorite OO extension", but I think we'll all be thankful
> in the end that I had at least enough sense to not do that.
>

Granted. BUT all other things being equal - and I think it is clear
that all the arguments we have now are in the metric-less space of
design philosophy - the dedication of the proponents of one solution
not only to their solution, but to the community as a whole is also a
factor. Particularly since you are really proposing putting in the
place of Itcl something that DOESN'T currently exist, and which you
will have to go out and solicit contributions or dedicate Scriptics
resources to write!

Jim

--
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jin...@cygnus.com
Cygnus Solutions, a Red Hat Company

Don Porter

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Don Porter wrote:
>>> But what about those developers who distribute packages which depend on,
>>> say, BLT? This doesn't do a thing for them. Should we also weld BLT
>>> into the core distribution? Where do we stop?

Denis Medvedev <m...@chat.ru> wrote:
>> Nowhere! My opinion is that TCL core distribution should include ALL
>> widely_used packages.

Clearly we stop somewhere. You've just hidden the decision about where
to stop behind the description "widely used".

Thomas Andrews <tho...@best.com> wrote:
> Isn't that stretching the word "core" a bit?

I think so, but in any case, if this is an issue underlying this debate,
it's best that we get it out on the table.

lvi...@cas.org

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

According to Thomas Andrews <tho...@best.com>:
:If I had to decide whose version of "if { ... } then { ... }" to use
:each time I used Tcl, I'd probably complain...

In fact, if you had to download a seperate extension, struggle to figure
out how this writer wanted you to configure and build it, sift through
doc that might not exist, or might be in man pages, or might be in html or
might be in some other format (latex, pdf, etc.), and had to do a package
require to USE the if, you would, in all likelihood, either quit using
Tcl or at least consider forbidding the use of if...

Allen Flick

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Not that I think anyone cares, but I've skimmed most of these
postings the last couple of days and I have to wholeheartedly
say that it's time to put personalities aside and move ahead.

Sometimes the best (Sony Beta format) is not the most favorite,
but the most favorite (Panasonic's, I believe, VHS format) has
the widest following, market penitration, & is quite adequate
to get the job done.

It doesn't matter here whether [iTcl] is the best, the most favorite,
or both. Me thinks it has gotten the most backing and it has been
stated that whatever OO system is chosen will NOT be part of
Tcl's core, just part of the core distribution. So, all the others can
continue to use whatever they want.

Jeffrey Hobbs has taken quite a beating today. Let's not forget
the good work he's done, too. Let's not always look for something
to complain about. (Heck man, I'm married to her!)

MOVE ON !!!

Oh, my vote? I've only used [iTcl] a little bit and the others I
haven't
touched. So, I'll officially abstain, but it'd be [iTcl] if I were to
cast
a vote.

==========================================
C. Allen Flick (ALF)
==========================================

Don Porter

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Thomas Andrews <tho...@best.com>:
>:If I had to decide whose version of "if { ... } then { ... }" to use
>:each time I used Tcl, I'd probably complain...

<lvi...@cas.org> wrote:
> In fact, if you had to download a seperate extension,

Distributing any package with the core distribution will save the users
of that package a download. Can't dispute that.

> struggle to figure
> out how this writer wanted you to configure and build it, sift through
> doc that might not exist, or might be in man pages, or might be in html or
> might be in some other format (latex, pdf, etc.),

All of these are matters which are supposed to be addressed by the
TEA conventions. There's no requirement that a package be added to
the core distribution before it can adopt TEA to reduce the burden
on its users. I think these issues are orthogonal to this discussion.

> and had to do a package require to USE the if,

So do you think people are going to object to evaluating [package
require oosystem] in their scripts before they can use the OO system
distributed with the core? Do people really want new built-in core
commands which support OO instead of just a package in the distribution?

I think I would understand that desire more easily than the mere
bundling of a package. OO commands actually in the core would supply
a truly "ubiquitous" object system. There would be no separate install,
and no need to [package require] anything.

The [if] command is builtin even though more primitive commands like
[return], [uplevel], etc. are available out of which you could build
your own [if] at either the C or Tcl levels. Likewise core Tcl could
provide a [class] while at the same time continuing to provide the
[namespace], [proc], etc. out of which one could roll their own [class].

Bundling a package saves you a download. Is there any more to it than
that? Is that enough?

Don Porter

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Thomas Andrews <tho...@best.com> wrote:
> I find myself constantly thinking in objects then having to "translate"
> those ideas to Tcl, a painful exercise most of the time, especially when
> efficiency is required.

Why continue in pain? Does the object model of Itcl suit your needs?
Why not download, install, and use it?

Tcl's design is for the core to be extended by packages. What are the
impediments to more users of Tcl using more of the available packages?
Is bundling packages with the core distribution the best way over these
obstacles?

Jeff David

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
Don Porter wrote:

>
> Bundling a package saves you a download. Is there any more to it than
> that?

Yes. It also ensures (or should ensure) that you have a version of the
package that is 100% with the version of Tcl you are running. That
alone makes it worthwhile.

It also makes it easier for people to get useful extensions. I'd bet
that the majority of Tcl USERS (but a small minority of posters to this
group) are put off by being required to go off into the hinterlands
of the internet (or even dev.scriptics.com) to grab an extension and
then deal with (in many cases) a problematic make/build process. Having
all of that in one distribution, supported by Scriptics would have a
tremendous benefit both to the users and the authors of the extensions.

I think we have to remember that the posters to this group are NOT
typical Tcl users. Most are experts who are used to having to
download and compile extensions. There is a whole other class of
user out there who want to program in Tcl AND use extensions with
a minimum of up-front fuss and bother. THAT is where the real
value of bundling lies.

Jeff David

James Ingham

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
d...@clover.cam.nist.gov (Don Porter) writes:

>
> Bundling a package saves you a download. Is there any more to it than

> that? Is that enough?
>

Yes, it means that once I have gotten Tcl, I have LOTS of cool stuff
to play around with before I have to go grubbing the net for other
packages. It means that what I have on disk includes a top-level doco
page that lists all the goodies I now have - preferably an
embarrasment of riches... Lots of people, based on the questions I
have fielded over time, are much less sophisticated in their "internet
resource search skills" than most of the people on this newsgroup.

Making available as the standard Tcl install, a huge Mega-package that
contains all the stuff I am likely to want, will ease this burden.

It is also a quality of development issue. There are lots of little
things like - I am developing some UI, and I think: "Wouldn't it be
cool to play some funky sound here, rather than just the system beep?"

If Snack is a standard part of the install, and I can just look up my
main doco, see "extension for playing & recording sounds" - package
require it, and voila, I have my neato effect, I will be a happy
camper. If I have to go to some web site, search around for such a
thing... I will probably just bag it, and use bell. I will not be
hugely disadvantaged, but Tcl will have lost an opportunity to really
impress me.

Jeffrey Hobbs

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to James Ingham, Jeff David, George A. Howlett
James Ingham wrote:
[good arguments for Itcl elided]

Right, so you all babble about this being a no-brainer, and I
know all the arguments already, true (which is why it can seem
like babbling to me). However, the whole intention of starting
this discussion was for everybody to understand the end
decision. Please note these comments to understand the true
basis of the conversation being repeated again *at this time*:

You continue to address me with the responses, but it is to
the Porter's in the group that things need to be made clear for:

--

Bruce Edge

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
James Ingham wrote:
>
> d...@clover.cam.nist.gov (Don Porter) writes:
>
> >
> > Bundling a package saves you a download. Is there any more to it than
> > that? Is that enough?
> >
>
> Yes, it means that once I have gotten Tcl, I have LOTS of cool stuff
> to play around with before I have to go grubbing the net for other
> packages. It means that what I have on disk includes a top-level doco
> page that lists all the goodies I now have - preferably an
> embarrasment of riches... Lots of people, based on the questions I
> have fielded over time, are much less sophisticated in their "internet
> resource search skills" than most of the people on this newsgroup.
>
> Making available as the standard Tcl install, a huge Mega-package that
> contains all the stuff I am likely to want, will ease this burden.

This is one of the issues that was brought to my attention when I was
looking at choosing a scripting language.
Python includes everything in it's distribution, and that is often touted
as a major benefit of the language, whereas in reality it has nothing
to do with the language per se, rather their chosen means of propagation.
I think this does make it easier for the novice to pick up a language and
be productive. One of my stumbling block while learning Tcl was that I
didn't know what was available for it library wise.
Sure, a little research on the www would have educated me, but when one
is confronted with a new language, it's kind of overwhelming. The urge
to make it more overwhelming by digging on the web just isn't there.
I vote for including lots of libs in the standard release tarball.

-Bruce.

> ++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
> Jim Ingham jin...@cygnus.com
> Cygnus Solutions, a Red Hat Company

--
Bruce Edge be...@sattel.com
Sattel Global Networks 818.709.6201 x122

Don Porter

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
(Don Porter) writes:
>> Bundling a package saves you a download. Is there any more to it than
>> that? Is that enough?

James Ingham <jin...@leda.cygnus.com> wrote:
> Yes, it means that once I have gotten Tcl, I have LOTS of cool stuff
> to play around with before I have to go grubbing the net for other
> packages.

That's the answer to a somewhat different question. (And I realize I've
been shifting around a bit.) I was asking about the benefits of
bundling one OO package. It saves a download. Also, it provides a
second opinion that this release of the OO package is compatible with
this release of Tcl, in case the author of the OO package got that
wrong.

You're now talking about the benefits of distributing a *huge* library
of packages with the core.

> If Snack is a standard part of the install, and I can just look up my
> main doco, see "extension for playing & recording sounds" - package
> require it, and voila, I have my neato effect, I will be a happy
> camper. If I have to go to some web site, search around for such a
> thing... I will probably just bag it, and use bell.

I'm not convinced there's a real difference here, assuming Internet
access, which I think is a reasonable assumption. If the huge library
is distributed with the core, I need some toplevel guide so I can find
what package will do what for me. Without that guide, I'll have no idea
what to [package require]. When I need a sound extension, unless I'm a
regular reader of c.l.t., "Snack" is not the first package name which
will come to mind.

Since you have to search for a package anyway, what difference does it
make if that search is through a master list of packages stored on your
local disk, or a master list maintained at a central web site? Finding
the package is the burden, and you can't avoid it. Once you've found a
package to use, download and installation is a snap, assuming TEA
compliance. If the list is on a web site, it can be kept up to date,
and it can be much larger, including packages of utility to a more
limited audience.

I suppose these two ideas need not be in conflict. One could set up
a package directory on the web, and also select a subset of the most
widely used packages for distribution with the core.

Jeffrey Hobbs

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to d...@cam.nist.gov
Don Porter wrote:

>
> Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> > Right, so you all babble about this being a no-brainer, and I
> > know all the arguments already, true (which is why it can seem
> > like babbling to me).
>
> Now, now. I don't see anyone babbling (except maybe myself). I do see

My bad, my babbling...

> 1. Why bundle any OO package with the core?
...
> But I'm still on point 1. And I'm most interested in the Tcl core
> team's own reasons for deciding that bundling an OO package with Tcl 8.4
> is necessary. The main technical reason I've seen so far is the
> shorthand reference "megawidget support".
>
> To me "widget" implies Tk, and Tk is not part of the Tcl core. If
> Tk 8.4 is going to need OO commands to add megawidget support, it may
> very well end up depending on an OO package in addition to its
> dependence on Tcl. Seems to me that's an indication that it's time for
> Tk to grow up, become an honest-to-goodness loadable package which will
> have to manage its dependence on other packages just like any other
> package with dependencies has to do.

> It's also been noted that some of the packages in tcllib might want to
> depend on an OO package. Seems to me that's a good argument for
> including the OO package in tcllib itself. This means lifting the
> restriction against C-coded packages in tcllib. It's not clear to
> me anymore whether the intent is to have tcllib in the core
> distribution or not.

Tk is just a step away from being a purely loadable package, but
that's another topic. The need for OO is "most evident" for megawidget
use, but a good OO package will benefit the breadth and reach of Tcl
overall (note how many people use [incr Tcl] without any use of Tk,
or iwidgets at least). Having OO is not requiring that users use it.
A proper C++ compiler will still compile all your C code just fine.
However, in the instances where you are pushing beyond the kernel of
the language, into providing functionality that the majority of users
will find uses for, an OO system will help a lot.

Can you imagine the management issues of building something like
tcllib without having namespaces (one of the core pieces of itcl and
for other OO systems)? Also, consider something as simple as the
stack struct. This structure can be built conceptually simpler,
code-wise cleaner, and runs faster in [incr Tcl] (ok, maybe it sucks
a bit more mem). We (the core team) started by thinking, "Boy,
ensembles in core would be really great", and the thinking doesn't
have to extend far before you realize that the core is (over)ripe
for an OO system (*optionally* available).

We are looking now to push beyond the focus of the kernel, into
providing functionality that almost every user should find some
benefit from. Many of these pieces would benefit from being able
to rely on a consistent OO system (not to mention the OO system
in and of itself).

So we choose [incr Tcl]? OK, not everybody is going to be happy,
but as we've seen from this discussion, it obviously has the
overwhelming support, for a variety of good reasons. Some have had
issues about mem footprint or speed, and we'll look into that and
float it by Michael. However, without another comparable system
that proves itself markably better, we shouldn't presume that what
we have available isn't the best solution (as Howlett points out,
comparing against vaporware is fruitless and somewhat
counterproductive).

The decision basically stands at [incr Tcl] for now, which isn't any
surprise for me (in spite of popular belief recently, I am not
anti-Incr). The purpose of this thread was basically to create the
discussion so that others see the benefit and advantages of the
end decision.

Jeffrey Hobbs

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to d...@cam.nist.gov

David Cuthbert

unread,
Apr 21, 2000, 3:00:00 AM4/21/00
to
Don Porter wrote:
> David Cuthbert <da...@kanga.org> wrote:
> > 1. Keeping everything up-to-date. We've already seen what happens with
> > numerous extensions when Tcl gets updated and the extension gets left
> > behind [...]

>
> This used to be a very big problem, because packages written in C had to
> have releases which tracked the releases of Tcl.
>
> This problem now has a solution: the stubs interface. Once a package
> written in C is stub-enabled, there is no longer this lockstep
> requirement on the releases. Stub-enabled foo 1.1 which happily loads
> into Tcl 8.1 will continue to happily load into Tcl 8.4,....

Assuming, of course, the old interfaces are still supportable in the new
Tcl. It's too early to say if this will remain true (I hope so).

> > 2. Support. Because it is an extension, getting support for our build
> > environment is very expensive. Presumably, if Tcl 8.4 included [incr Tcl]
> > or a compatible alternate, getting this support would be easier. (Or is
> > this a pipe dream of mine?)
>
> I'm not sure I completely follow this. Probably because lots and lots
> of issues get thrown into that word "support".

By support, I'm referring to Scriptics' TclCare support. (Sorry, I
discussed this earlier on the Itcl listserv and figured it was clear here,
since Tcl users can read minds, right? :-) [incr Tcl] support requires the
premium level, which is (from my budget's perspective) fairly expensive.

> I agree that including Itcl in the Tcl distribution probably means
> improved support for Itcl. That's certainly a benefit to the users of
> Itcl. But what's in it for the rest of the Tcl users? Can't improved
> support for Itcl be provided by other means than placing it in the core
> distribution?

Probably. But nobody is providing Tcl support other than Scriptics right
now. And unless you phone in your pledge at the $25,000 level... :-)

> This is a benefit for developers who wish to distribute packages which
> depend on Itcl. It shortens their instructions. Currently they have to
> say: 1) Download and install Tcl 2) Download and install Itcl
> 3) Download and install my package. If Itcl is distributed with Tcl,
> they can drop step 2.
>

> But what about those developers who distribute packages which depend on,
> say, BLT? This doesn't do a thing for them. Should we also weld BLT
> into the core distribution? Where do we stop?

Good point. From my perspective, a core language distribution -- to be as
useful as possible -- should include all language-based features (control
structures, component management, etc.). In my mind, this includes an OO
system. Why should I bother with a language that doesn't intrinsically
support OO (and, specifically, OO that I find useful)?

Note: Tcl was *not* my first choice of language for the project I'm working
on; in fact, the early prototypes used Python. Tcl was "forced" on me by
management. I found it to be very painful to maintain Tcl code when the
project grew beyond 1-2 kloc. I got so frustrated that I started to write
my own object system when, lo and behold, I discovered Itcl. Life has been
pretty good since.

The other extreme is a language whose basic features aren't much beyond C
(aside from being interpreted). For example:

/home/dacut: tclsh8.4
% puts "Hello world!"
invalid command name "puts"
% exit
/home/dacut: ftp ftp.scriptics.com
(yadadada... download packages/fileservices.tar.gz, compile, etc.)
/home/dacut: tclsh8.4
% package require fileservices 1.0
1.0
% puts "Hello world!"
Hello world!

(I'm thinking, of course, of C's "#include <stdio.h>" equivalent here).

> The fundamental problem is that it is a pain to find and install a
> compatible collection of Tcl packages needed to support a particular Tcl
> application. I'd rather have the efforts of the Tcl community channeled
> toward solving that general problem instead of working around it by
> adding more and more packages to the core distribution. Supplying the
> workaround actually decreases the demand for the general solution and
> delays it further.

Hmm... interesting point. A "package require" that is smart enough to grab
what it needs over the Internet, maybe?

> > I'd prefer [incr Tcl] or a compatible alternative because:
> > 5. Ease of transition. The less I have to rewrite, the faster I can transit
> > to the brand-spankin' new Tcl 8.4, and the fewer bugs I introduce in the
> > process.
>
> Again, I fail to see why there's any transition required at all. No
> matter what packages ship with the Tcl core distribution, so long as Tcl
> 8.4 maintains the backward compatibility it is supposed to, your
> stub-enabled Itcl package will keep working and all your current uses of
> Tcl+Itcl should continue working as before.

Except I've made the decision to go with whatever OO system Scriptics
decides to ship with 8.4--assuming that one does ship, and it isn't of
excessively low quality (which I highly doubt would happen).

If, for whatever reason, Tcl 8.4 doesn't ship with an OO system, I will
continue bundling Tcl with Itcl for our customers, which is more work for
me. Remember, I'm lazy. In fact, I'm so lazy, I was going to have my
middle name changed to "lazy," but I'm too lazy to even do that...

Ahem... where was I? Oh, yes...

At any rate, I dislike having Tcl (and Tk, Itcl, Itk, and Iwidgets) source
in our tool's software tree, as we did for Itcl 3.0 and Tcl/Tk 8.1 plus a
lot of bug fixes to kludge them together. Itcl 3.1 would have solved this,
but we shipped (or were scheduled to ship, at least) too early for this to
happen. (In retrospect, I should not have upgraded to Tcl/Tk 8.1.) I'd
rather have Scriptics do that work for me.

One other benefit I see for Tcl users (though you may disagree) is they will
be able to use extensions that use Itcl even if they don't use Itcl
themselves. Using an Itcl class is no different than running any other Tcl
command that returns a command-token (like the Tk widgets).
--
David Cuthbert
da...@kanga.org

lvi...@cas.org

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