Why so many Object-oriented TclTk implementations? 
Author Message
 Why so many Object-oriented TclTk implementations?

It seems that we've got 5 or 6 object oriented Tcl/Tk implementations
these days.

I haven't used any of them, but I've been planning to use Incr Tcl when
it came out for Tcl 8.0 since I don't get to use C++ often enough to get
any OO practice.

The delay of the Incr Tcl release for Tcl 8.0 seems to have inspired at
least one of the newer implementations.

I'm sure many will disagree with me when I say that I wish there were
just one implementation. But, wouldn't this focus resources and
ultimately feed stability, longevity, sharability of apps, widgets, etc?

Probably most people would agree that a Tcl-only implementation is
preferred. I believe most (if not all) implementations are Tcl-only,
including the planned next release of IncrTcl.

I've always assumed that Incr Tcl is most widely used. I'm surprised
that other people even bothered to write their own. Has the Incr Tcl
author abandoned the project?

Is there a comparison of the various implementations anywhere?

--
...RickM...



Fri, 06 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?

Quote:
>I'm sure many will disagree with me when I say that I wish there were
>just one implementation. But, wouldn't this focus resources and
>ultimately feed stability, longevity, sharability of apps, widgets, etc?

As the author of tcl++ (http://www.sensus.org/tcl) I do agree. I started out
trying to implement a poor-mans incrTcl - but rapidly abandoned that in
favor of a tcl-only incrTcl clone - as almost all the feedback I got was
alone the lines of making it more compatible w/ incrTcl.

If no OO extensions had existed I probably wouldn't have done one the way
incrTcl does it, but having said that [incrTcl] is far and away the most
popular OO extension, so as they say "go with the flow....".

I have used incrTcl in several compaines for mission-critical functions -
it's good, it's quite fast, and most importantly its widely used and
therefore there is alot of incrTcl code around.

Tcl++ is intended to fill the need people have for a Tcl 8.0
implementation - in its current form it passes all significant compatibility
tests. It also serves as a leading-edge for incrTcl, since it can be ported
far more rapidly.

I would like to go on record as saying - I have NO interest in competing w/
incrTcl.

Quote:
>Probably most people would agree that a Tcl-only implementation is
>preferred. I believe most (if not all) implementations are Tcl-only,
>including the planned next release of IncrTcl.

The next version of incrTcl will not be tcl-only - as speed suffers.

Quote:
>I've always assumed that Incr Tcl is most widely used. I'm surprised
>that other people even bothered to write their own. Has the Incr Tcl
>author abandoned the project?

No he hasn't - Mike is simply busy, in some senses a victim of his own
sucess.

Quote:
>Is there a comparison of the various implementations anywhere?

Not that I know of. Many are super-simple, fine if you want a very
lightweight structure for your code. Many more unfortunately fall into the
category that I think prompted your mail, that of esthetic differences. Like
the desire for more smalltack-like syntax, or more Java-like etc etc.

IMHO incrTk is by far the most sophesticated mega-widget implementation
available today, and frankly in JohnO had taken Mike's work in the first
place (esp. the namespace part) we would all be futher ahead.

Tcl as a community can only suceed if we pool our efforts rather than trying
to compete with each other. We are simple not yet big enough to be engaging
in such practices.

Matt Newman



Fri, 06 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?

Quote:

> I've always assumed that Incr Tcl is most widely used. I'm surprised
> that other people even bothered to write their own. Has the Incr Tcl
> author abandoned the project?

As the author of Tea, I'll state my reasons for bothering. [incr tcl]
is/was by far the best OO implementation. But I grew weary of its C++
similiarities and didn't care for the widgets package. I also tired of
waiting so long for a Tcl-only implementation. So I wrote Tea. I don't
think the [incr tcl] author has abandoned it, but I was surprised to finish
Tea and release it before itcl3.0 arrived.

Quote:
> Is there a comparison of the various implementations anywhere?

The Tea website, http://www.doitnow.com/~iliad/Tcl/tea, has a FAQ that very
briefly compares Tea with incr tcl:
http://www.doitnow.com/~iliad/Tcl/tea/tea_faq.html.

Quote:

> --
> ...RickM...

John Stump


Fri, 06 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?



Quote:
>>I'm sure many will disagree with me when I say that I wish there were
>>just one implementation. But, wouldn't this focus resources and
>>ultimately feed stability, longevity, sharability of apps, widgets, etc?

>As the author of tcl++ (http://www.sensus.org/tcl) I do agree. I started out
>trying to implement a poor-mans incrTcl - but rapidly abandoned that in
>favor of a tcl-only incrTcl clone - as almost all the feedback I got was
>alone the lines of making it more compatible w/ incrTcl.

>If no OO extensions had existed I probably wouldn't have done one the way
>incrTcl does it, but having said that [incrTcl] is far and away the most
>popular OO extension, so as they say "go with the flow....".

>I have used incrTcl in several compaines for mission-critical functions -
>it's good, it's quite fast, and most importantly its widely used and
>therefore there is alot of incrTcl code around.

>Tcl++ is intended to fill the need people have for a Tcl 8.0
>implementation - in its current form it passes all significant compatibility
>tests. It also serves as a leading-edge for incrTcl, since it can be ported
>far more rapidly.

>I would like to go on record as saying - I have NO interest in competing w/
>incrTcl.

>>Probably most people would agree that a Tcl-only implementation is
>>preferred. I believe most (if not all) implementations are Tcl-only,
>>including the planned next release of IncrTcl.

>The next version of incrTcl will not be tcl-only - as speed suffers.

>>I've always assumed that Incr Tcl is most widely used. I'm surprised
>>that other people even bothered to write their own. Has the Incr Tcl
>>author abandoned the project?

>No he hasn't - Mike is simply busy, in some senses a victim of his own
>sucess.

>>Is there a comparison of the various implementations anywhere?

>Not that I know of. Many are super-simple, fine if you want a very
>lightweight structure for your code. Many more unfortunately fall into the
>category that I think prompted your mail, that of esthetic differences. Like
>the desire for more smalltack-like syntax, or more Java-like etc etc.

>IMHO incrTk is by far the most sophesticated mega-widget implementation
>available today, and frankly in JohnO had taken Mike's work in the first
>place (esp. the namespace part) we would all be futher ahead.

>Tcl as a community can only suceed if we pool our efforts rather than trying
>to compete with each other. We are simple not yet big enough to be engaging
>in such practices.

>Matt Newman

The problem with incrTcl is that it's too big as a C extension to
upgrade rapidly. I used to use it a lot, but it lags so far that I quit
waiting. Tix is also relatively large and isn't really oo in the sense
of the discussion. Mit otcl is relatively small and was ported to 8.0
relatively quickly, but even though Gustav Neumann & I have waded
through the code quite quickly I'm certain I wont be so eager to make it
thread safe. I've also balked at porting BLT2.3 to Win32. Tcl/Tk seems
the way to go except for the speed penalty. The tcl++ incrTcl clone
worked very well for me, but was too slow for the intended use (lots of
limited entry widgets) the redraw time was longer than the computation
of the results (1 entry changed up to 200) and the timing effects under
NT4.0 were a bit hypnotic.
--
Robin Becker


Sat, 07 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?

Quote:


> > I've always assumed that Incr Tcl is most widely used. I'm surprised
> > that other people even bothered to write their own. Has the Incr Tcl
> > author abandoned the project?

> As the author of Tea, I'll state my reasons for bothering. [incr tcl]
> is/was by far the best OO implementation. But I grew weary of its C++
> similiarities and didn't care for the widgets package. I also tired of
> waiting so long for a Tcl-only implementation. So I wrote Tea. I don't
> think the [incr tcl] author has abandoned it, but I was surprised to finish
> Tea and release it before itcl3.0 arrived.

My 2 cents.

If John Ousterhout had adopted an official oop extension, then there wouldn't
be as many as there are.

But he didn't and I don't think he will.

BTW, I was thinking of writing my own oop ! :)

Cheers

--
-------------------------------------------------------------|
          Remember Scotch: 'THERE CAN BE ONLY ONE'           |
-------------------------------------------------------------|
| Daniel J. Rodriksson       | B-203,ETSI Telecomunicaciones |

| http://www.dit.upm.es/~djr | 28040 Madrid                  |
| +34-1-3367366 + ext 809    | SPAIN                         |
|------------------------------------------------------------|



Sat, 07 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?


:It seems that we've got 5 or 6 object oriented Tcl/Tk implementations
:these days.

Let's see, in the software catalog at
<URL:http://www.teraform.com/%7Elvirden/tcl-faq/part5.html> I see

BOS - builds objects in a manner similar to the SELF language
CASTE - objects implemented based on Common Lisp Object System
Fcl - persistent objects based on Aesop
[incr tcl] - supports Tcl 7.6, tries to retain the tcl philosophy
jTcl - Java like objects
minterp - Tcl 6 based effort
Object Tcl - allows tight object coupling to C++
Object-Tcl - multi-inheritence in a Tk widget fashion
ObjectiveTcl - Commercial product intefacing to Objective-C
obTcl - Tcl 7.5, written in Tcl
MIT otcl - dynamic OO, featuring inheritance, meta objects, automatic methods,
        mixing of C and C++.
scwoop/stooop - simple Tcl based object and composite widget systems,
        runs under Tcl 8.
SNTL - general set of procedures which includes and object system.
STERNO - structured data encapsulation and management, based on Tcl 8,
        does no inheritence.
Tcl++ (Gkioulekas) - extends interpreters as well as adds a small object
        extension
Tcl++ (Newman) - Tcl 8 based (and tcl source only) OO designed to work
        like incr tcl.
Tcl++ (ssinnge) - adds objects to Tcl 8 in the style of C++ and Java
        with multiple inheritance, virtual functions, and RTTI.
theObjects - prototype for an OO system
this - easy way to build Tcl objects
TWO - Tcl With Objects.  Instance variables are accessed like local variables

This is a rough cut - I didn't count thinks like interfaces to object
oriented databases, interfaces to C++, Java, or Objective C objects,
and a few other similar extensions because they didn't seem like they fit.

The pattern I see from the brief description is that many of the extensions
try to implement another language's style of object into Tcl.  I can
think of three reasons to do this - one would be to interface better with the
language in question.  Another would be to cater to a programmer comfortable
thinking in the other language.  The last would be to bring the good ideas
from one language into another language intended to be extended.

:I'm sure many will disagree with me when I say that I wish there were
:just one implementation. But, wouldn't this focus resources and
:ultimately feed stability, longevity, sharability of apps, widgets, etc?

Perhaps.  However, it could also result in stagnation, false starts,
and limitations because other approaches were not considered.

:Probably most people would agree that a Tcl-only implementation is
:preferred. I believe most (if not all) implementations are Tcl-only,
:including the planned next release of IncrTcl.

I don't know.  A Tcl only implementation might make it easier for someone
to begin using the extension.  However, it can also result in a lot
of frustration if the implementation isn't fast enough.

What I _do_ think we can all agree on is that people prefer implementations
which do not require modifying the Tcl or Tk core code, and that can
be used without concern with and by other extensions.

:I've always assumed that Incr Tcl is most widely used. I'm surprised
:that other people even bothered to write their own. Has the Incr Tcl
:author abandoned the project?

No - however, the conversion to Tcl 8 apparently is quite difficult,
and the author has a life (and job) outside itcl.

:Is there a comparison of the various implementations anywhere?

No - but I would love to find someone who knows OO design and a variety
of language implementations who would like to take on the challenge.

P.S.  If anyone knows of other object oriented extensions for Tcl that
are available and not mentioned above, send me a note.  If they are
not in the catalog, I will add them.  If they are, I will see why
I missed them in my list above and try to do better next time.

--

<*> O- <URL:http://www.teraform.com/%7Elvirden/> only planning.
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.



Sat, 07 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?

Hi,

Quote:

> (snip) (Pure) (snip) Tcl/Tk seems
> the way to go except for the speed penalty. The tcl++ incrTcl clone
> worked very well for me, but was too slow for the intended use (lots of
> limited entry widgets) the redraw time was longer than the computation
> of the results (1 entry changed up to 200) and the timing effects under
> NT4.0 were a bit hypnotic.

> Robin Becker

Does anyone else have experiences with Tcl 8.X and tcl++
performance-wise?

We are using Tcl 7.6 and would love to go to 8.X but are waiting for
[incr Tcl]. Tcl 8.X gives performance improvements because of the
compiler, where tcl++ gives performance penalties because of it's tcl
implementation. Do they outweigh each other? Our implemenation would
love to use 8.X features, but can not bear significant degradation in
performance...

In light of this discussion, we are going to try to do a comparisson
ourselves, but would love any experiences any of you have in this
field... What in tcl++ is slow, what is fast, preferred ways to do
things to improve speed, that sort of thing...

Seeya,

:-)

Peter Morch

Manager - Automated Testing Development
GN Nettest Canada

Telephone: (+1) 905-479-8090 Ext. 455
FAX      : (+1) 905-475-6524



Sat, 07 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?

Quote:
>In light of this discussion, we are going to try to do a comparisson
>ourselves, but would love any experiences any of you have in this
>field... What in tcl++ is slow, what is fast, preferred ways to do
>things to improve speed, that sort of thing...

FWIW, I did some comparisons of Sterno, tcl++ (1.0) and obstcl, a very
small package I wrote. See

  http://ptolemy.eecs.berkeley.edu/~johnr/code/obstcl/

We're "porting" some code to tcl++ now as an exercise.
Basically, being itcl-compliant takes code, which costs
time. If anyone does do more work on this I suggest submitting
a poster to the Tcl/Tk conference.

JohnR



Sun, 08 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?


:time. If anyone does do more work on this I suggest submitting
:a poster to the Tcl/Tk conference.

Boy, a comparison of Tcl object oriented programing extensions would be a
VERY popular session, poster, BoF, whatever.

For that matter, I think it would make a great Dr. Dobbs article...

--

<*> O- <URL:http://www.teraform.com/%7Elvirden/> only planning.
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.



Sun, 08 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?

Quote:

> The problem with incrTcl is that it's too big as a C extension to upgrade
> rapidly. I used to use it a lot, but it lags so far that I quit waiting.

This statement mirrors my fundamental belief that Tcl extensions
should try to provide a Tcl-only substitute implementation of any
C-coded feature.  This would allow the extension to be used (with
some limitations) without requiring it to be compiled.  This gives
the extension further platform and version portability, as it may
continue to be used even when a port of the C-coded portion hasn't
happened.

Some good examples of this are:
        Stoop, obTcl
                The C-coded portions of these OO extensions are optional
                and exist only top boost performance.  Both extensions
                work identically, albeit slowly, without the compiled portion.

        Matt Newman's Tcl++
                This Tcl-only OO extension aims for incr-Tcl
                compatibility.  He's apparently done a great job, leaving
                out just a few select area where 100% compatibilty isn't
                feasible.  I humbly suggest that the next incr-Tcl release
                include something close to this as a fallback Tcl-only
                implementation.

John



Sun, 08 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?



                        .
                        .
                        .

Quote:
>This statement mirrors my fundamental belief that Tcl extensions
>should try to provide a Tcl-only substitute implementation of any
>C-coded feature.  This would allow the extension to be used (with
>some limitations) without requiring it to be compiled.  This gives
>the extension further platform and version portability, as it may
>continue to be used even when a port of the C-coded portion hasn't
>happened.

>Some good examples of this are:
>    Stoop, obTcl
>            The C-coded portions of these OO extensions are optional
>            and exist only top boost performance.  Both extensions
>            work identically, albeit slowly, without the compiled portion.

>    Matt Newman's Tcl++
>            This Tcl-only OO extension aims for incr-Tcl
>            compatibility.  He's apparently done a great job, leaving
>            out just a few select area where 100% compatibilty isn't
>            feasible.  I humbly suggest that the next incr-Tcl release
>            include something close to this as a fallback Tcl-only
>            implementation.

>John

NeoWebScript <URL:http://www.developer.com/news/techfocus/032398_neoweb.html>
comes in both pure-Tcl and compiled-from-C flavors.
--

Cameron Laird           http://starbase.neosoft.com/~claird/home.html



Sun, 08 Oct 2000 03:00:00 GMT  
 Why so many Object-oriented TclTk implementations?

Quote:


> > I've always assumed that Incr Tcl is most widely used. I'm surprised
> > that other people even bothered to write their own. Has the Incr Tcl
> > author abandoned the project?

I also wrote a Java Like extention http://www.fridu.com because I wanted
a Tcl only extention and Stoop did not fit my requirement.

The problem comes from Sun that did not choose one implementation
I think core Tcl should have one and only one object extention, this extention

should be very easy to map with C++ and Java, as easy as to map Tcl and C.

In jTcl it is possible to overload one method from a C++ class in Tcl
and would like the same mecanism in Java, but have no time and
not enought interest to write it.

My conclusion: we need a unique object technology in core Tcl.

Phillf



Sun, 08 Oct 2000 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. ANNOUNCEMENT: Object-Oriented Systems - new object-oriented journal

2. ANNOUNCEMENT: Object-Oriented Systems - new object-oriented journal

3. New Book: Object-Oriented Implementation of Numerical Methods

4. Object-Oriented Implementation of Numerical Methods by Didier Besset

5. CFP-OOPSLA 98 WOrkshop on Implementation and Application of Object Oriented Workflow Management Systems

6. Deadline extension-CFP-OOPSLA 98 Workshop on Implementation and Application of Object Oriented Workflow Management Systems

7. Object Oriented language implementation

8. Why Object-Oriented JavaScript is ideal for GOFAI

9. Why isn't Math object-oriented?

10. Compare object-oriented and function-oriented ....

11. Action-oriented vs Object-oriented

12. Object Structures - Building Object-Oriented Software Components with Eiffel- By Jacob Gore

 

 
Powered by phpBB® Forum Software