OO extensions for TCL
Pier Luigi RATTO
I know at least three object oriented extensions for TCL:
OTCL by David Wetherall, ftp://ftp.tns.lcs.mit.edu/pub/otcl/;
Object TCL, http://www.x.co.uk/devt/ObjectTcl/;
[incr tcl] by Michael J.McLennan,
ftp://harbor.ecn.purdue.edu/pub/tcl/extensions/.
Could anyone help me to choose ?
Thank you in advance.
--
Pier Luigi RATTO Ansaldo Trasporti SPA
E-mail pi...@gepf44.atr.ansaldo.it Via dei Pescatori 35
tel. 039-10-6552138 16129 Genova, Italy
fax 039-10-6552384
Larry W. Virden:
I noticed the following in the report from the Tcl/Tk 95 workshop.
Is Shannon around to point us to an online version of this presentation?
I know this isn't what you particularly asked about - you were wanting an
evaluation of OO extensions. There was also a session just talking about
the OO extensions - unfortunately the session notes do not provide a lot
of help for selection.
Mega-widgets in Tcl/Tk - Shannon Jaeger
Presented by Shannon Jaeger
Shannon developed a framework for evaluating mega-widgets, which she
then used to evaluate six different mega-widget extensions.
A mega-widget is defined as "a collection of primitive widgets".
A mega-widget extenion is defined as "an application that extends the
functionality of Tcl/Tk...". Mega-widgets should look like traditional
Tk widgets to the application builder: it should provide a creation
command, widget command, configure options, widget suboptions, and
possibly widget component access. The widget builder needs support from
the mega-widget extension for implementing the creation command, widget
command, parsing, and default behavior. The widget builder would also
like subcommand support: creating new subcommands and re-using
existing subcommands, in addition to parsing and namespace/scoping
issues. Additionally, the widget builder needs configuraiton option
support: creation of new ones, define handlers, re-use, parsing, and a
rich model of propagation to sub-components.
[incr Tcl], Wigwam, [incr Tk], Tix, TkMegaWidget, and theObjects were
investigated. These packages tended to trade-off Housekeeping vs. Flexibility;
you tended to get either one or the other. All were weak on the component
access and supporting Tk commands such as winfo children.
--
:s Larry W. Virden INET: larry....@cas.org
:s In search of a new WWW home...
:s Unless explicitly stated to the contrary, nothing in this posting should
:s be construed as representing my employer's opinions.
George A. Howlett
software of the Mars Pathfinder. [See David Smyth's paper in the
Proceedings of the Tcl/Tk 1994 Workshop pp. 3-9) for details.]
> but its class definitions are static (can't be changed)
Not true. This is one of the "Top 10 Myths of [incr Tcl]" that
Michael McLennan debunked at the last Tcl/Tk workshop.
There's nothing to prevent you from generating new classes dynamically.
And since Tcl is type-less you can always use an array variable to
add (mutate) a class instance (just like the slots-based approaches).
> and it doesn't have an API (that I know of).
The new release (itcl 2.0) will have allow you to have C methods.
[And one of the biggest and best new features (IMHO) is real namespaces.]
This isn't a criticism of the other OO extensions. I just want to set
the record straight.
--gah
Michael J. McLennan
: [incr tcl] is a good idea, but its class definitions are static
: (can't be changed) and it doesn't have an API (that I know of).
This is a common misconception about [incr Tcl] that I would like to
correct. It is true that [incr Tcl] has a notion of strong classes.
In other words, if you understand the class definition, you know
everything there is to know about the object. This makes large
projects (with lots of code or lots of programmers) easier to
understand and maintain. If there there are five lines of code sitting
off in the corner that can completely change the behavior of my object,
and if someone else added those lines, it can lead to long nights of
painful debugging.
But although [incr Tcl] has strong classes, it is not "static".
After all, it is sitting on a very dynamic interpreter. Attached
below is an [incr Tcl] class called "Object" which reproduces much
of the functionality in David Wetherall's OTCL package. Using this
class, you can create a generic itcl object and customize it to act
like a stack:
source otcl.itcl ;# see class definition below
Object astack
astack member things {}
astack method put {thing} {
instvar things
set top [lindex $things 0]
set things [linsert $things 0 $thing]
return $thing
}
astack method get {} {
instvar things
set top [lindex $things 0]
set things [lrange $things 1 end]
return $top
}
puts "=> [astack do put toast]"
puts "=> [astack do put muffin]"
puts "<= [astack do get]"
puts "<= [astack do get]"
astack delete
This example reproduces the one in OTCL workshop paper almost exactly.
Notice that the member "things" was added after the object was created.
Other data members could be added on the fly as well. Similarly, the
methods "put" and "get" were added on the fly, and these could be
redefined, or new methods could be added as needed.
The simple "Object" class shown below does not support inheritance,
but this could be added with 100 lines of code and a couple more hours.
But the point is this: It's not that [incr Tcl] *can't* support more
dynamic objects, but that I encourage people to use the more static
paradigm. Having dynamic objects is interesting and perhaps even
elegant for small, one-man projects. But for large projects, I believe
that it leads to write-only code.
Besides, there are a number of nifty things coming in the next [incr Tcl]
release, including: mega-widgets, namespaces, a C/C++ API, full support
for public/protected/private data members and member functions, and better
support for interactive development. Another posting to this newsgroup
has more details about the next release.
: Object TCL is an excellent idea (good C++ API) but I haven't
: been able to compile it *yet*. Its source code makes too many
: assumptions about the C++ compiler for it to be portable.
I am a big fan of Dean Sheehan's Object Tcl package, and I hope
to work more closely with him in the future. I see [incr Tcl] and
Object Tcl as two different parts of a much larger solution. Object Tcl
helps you bring C++ objects up to the Tcl language level, and [incr Tcl]
helps you create new objects at the Tcl language level. You might use
both of these packages for different parts of the same project.
: OTCL is my favorite so far. It's small, dynamically extensible
: and has a good API for C/C++ objects. Its only drawback is that
: you need tcl7.4 to use it. OTCL is very close to Objective C in
: its approach.
OTCL has a few other drawbacks as well. See my response in the
"Itcl + Tk4.0/Tcl7.4" thread in this newsgroup.
--Michael
=--=== ///////////////////////////////////////////////////////////
=-----==== Michael J. McLennan 2C-226 michael....@att.com
=------===== AT&T Bell Laboratories
==----====== 1247 S Cedar Crest Blvd Phone: (610) 712-2842
========== Allentown, PA 18103 FAX: (610) 712-2773
====== ///////////////////////////////////////////////////////////
#
# CLASS: Object
# DESCRIPTION: dynamic objects similar to OTCL
#
itcl_class Object {
protected memberInfo
method member {var {val "__@@default"}} {
if {$val != "__@@default"} {
set memberInfo($var) $val
}
return $memberInfo($var)
}
protected methodInfo
method method {name args body} {
lappend methodInfo(all) $name
set methodInfo($name-args) $args
set methodInfo($name-body) $body
}
method instvar {args} {
foreach var $args {
if {[info exists memberInfo($var)]} {
uplevel "upvar 0 memberInfo($var) $var"
} else {
error "unknown variable \"$var\""
}
}
}
method do {option args} {
if {![info exists methodInfo($option-args)]} {
error "unknown method \"$option\""
}
set __i 0
foreach __arg $args {
set __defn [lindex $methodInfo($option-args) $__i]
if {$__defn == ""} {
error "called method \"$option\" with too many arguments"
}
set [lindex $__defn 0] $__arg
incr __i
}
foreach __defn [lrange $methodInfo($option-args) $__i end] {
if {[llength $__defn] != 2} {
error "missing argument \"[lindex $__defn 0]\" for method \"$option\""
}
set [lindex $__defn 0] [lindex $__defn 1]
}
eval $methodInfo($option-body)
}
}
David J. Wetherall
>Carl D. Roth (ro...@cse.ucsc.edu) wrote:
>: [incr tcl] is a good idea, but its class definitions are static
>: (can't be changed) and it doesn't have an API (that I know of).
>This is a common misconception about [incr Tcl] that I would like to
>correct ... although [incr Tcl] has strong classes, it is not "static".
>After all, it is sitting on a very dynamic interpreter. Attached
>below is an [incr Tcl] class called "Object" which reproduces much
>of the functionality in David Wetherall's OTCL package. Using this
>class, you can create a generic itcl object and customize it to act
>like a stack:
it's not a misconception - your example is all smoke and mirrors michael.
look at the class definition - you've built a facade on top of
a class so that it appears extensible for this example. the point is that
OTcl provides much more dynamic extensibility, and it's built in. you can
emulate things that aren't provided in the language for particular examples,
but why not use the real thing?
> source otcl.itcl ;# see class definition below
>
> Object astack
>
> astack member things {}
>
> astack method put {thing} {
> instvar things
> set top [lindex $things 0]
> set things [linsert $things 0 $thing]
> return $thing
> }
>
> astack method get {} {
> instvar things
> set top [lindex $things 0]
> set things [lrange $things 1 end]
> return $top
> }
>
> puts "=> [astack do put toast]"
> puts "=> [astack do put muffin]"
> puts "<= [astack do get]"
> puts "<= [astack do get]"
>
> astack delete
> ...
this static thing is pretty ridiculous. i'm surprised by your line of
argument, since i can't imagine how itcl could be less dynamically extensible,
given that it's interpreted to begin with. the language doesn't help you
change existing classes at all.
in OTcl you can do things like:
add methods/instance variables to existing objects/classes
change the class of an existing instance
change the superclasses of an existing class
destroy/rename existing classes/objects
itcl doesn't support these things, and that's the point,
djw
Lee Hounshell
: in OTcl you can do things like:
: add methods/instance variables to existing objects/classes
: change the class of an existing instance
: change the superclasses of an existing class
: destroy/rename existing classes/objects
: itcl doesn't support these things, and that's the point,
Hmmm... I haven't selected either of these packages for use yet, but I have
been following the discussion and have also downloaded the available code.
Michael is trying to point out that even though self-modifying code "sounds"
like a good idea, it probably would be a nightmare for a large project.
Being a C++ programmer for very large object implementations for the
telecommunications industry (systems > 1 million lines of code) I have
to say I agree with Michael's point. MOST of the time, I do not want
bits of code lying about that can modify an object's behavior. It just
doesn't make for a maintainable system when more than one programmer
is working on it, and lots of source is involved.
David, a question for you:
Can you please show us an example of otcl where the "strong typed"
object implementation is used? Or is this not possible using otcl?
Thanks for your enlightenment.
-Lee Hounshell
l...@tcsl.com
Olaf Schlueter
> in OTcl you can do things like:
>
> add methods/instance variables to existing objects/classes
> change the class of an existing instance
> change the superclasses of an existing class
> destroy/rename existing classes/objects
>
> itcl doesn't support these things, and that's the point,
>
Please, give one good reason, why I should want that. I can easily
imagine a couple of situations, where I definitely don't want anything
like that. Do I want to program object-oriented because it is in or
because it buys me something ?
I am programming object-oriented, as it helps me to organize my code. Not that
I could not organize assembler or C or TCL code. You can organize anything
using policies. If you happen to be the one and only master of your code, you
are in the lucky position to always know the policies currently in operation
whether they are enforced by the language or just by your mood. But I work
in a team. Moods differ. Policies differ as well. I can not rely on
my buddies to follow some "Please, do it this way" policies. But I can rely
on the rules enforced by the language, if the whole team happens to
program in that language.
One of the rules of C++ (and itcl) is: "All objects of the same class
behave the same way". OTcl does not garantuee that. If I read code and
see an object, it is not sufficient to know the class of this object
to know what it is capable of, I need to know its whole history during
program lifetime. That is to anticipate every possible way to reach
a single point of execution, which is proven to be impracticle in all
but small sized applications.
I agree that this rule is nowhere as strong enforced by itcl or otcl as it
is in a type-safe language like C++. This is due to the type-less nature
of TCL in general. However, itcl pushes you in the C++ direction to do it
the "right way". After an object is instantiated, its behaviour is determined.
Another valuable rule of C++ is: "You can change everything in a class
which is private". itcl does not have private members (yet) which I
considered a flaw ever since, and I am glad to here that the next
release will have private members. As otcl garantuees nothing about an
object it naturally does not have a concept of
private/protected/public class members. It would not make any sense to
make such an distinction in otcl. But sealing is essential during
implementation of classes. I can change a class implemention without the
risk of having any aspect of the former implementation be used by foreign
code. If I publish an interface I have to stick to what I have said.
With sealing I don't need to make promises I cannot keep.
As fas as I have seen from the otcl paper, you can program in otcl
using "C++" style. The itcl_class { } wrapper is not really the big
difference. However, the "advantages" of otcl, as listed by David
above, do not persuade me. Waiting to hear reasons to change my mind,
I consider them weapons: use them with care, avoid them whereever
possible - they can kill your program.
--
--
Olaf Schlüter, System Administrator, Olaf.Sc...@mdc.netuse.de
Medical Diagnostic Computing GmbH, Düppelstr. 71, 24105 Kiel, Germany,
Office Voice: 49-431-804220, Fax: 49-431-804230
Geoffrey Furnish
> From: "David J. Wetherall" <djw>
> in OTcl you can do things like:
>
> add methods/instance variables to existing objects/classes
> change the class of an existing instance
> change the superclasses of an existing class
> destroy/rename existing classes/objects
>
> itcl doesn't support these things, and that's the point,
You really must explain to us how these language features of otcl
promote "good program design". The import of your claim is completely
lost on me. /Why/ would I want to do any of these things? When I
look at this list, I think to myself, "if my coworker on this project
started doing any of those things, I would strangle him."
Please give actual coded examples, in this forum, which demonstrate
these langauge features, and exhibit "good program design". Show me
an example where it "makes good sense" to change the base class of an
object, change the class affiliation of an existing object, etc.
In my current, apparently severely uninformed, state, I cannot begin
to imagine why I would want to use a language which supported this
sort of programatic mele. Your claim that "otcl is better than itcl"
is looking more and more specious. But I am still (for now)
listening. And hoping that you will start citing some actual reasons
to support your claims.
Downgrading to "suspicious",
--
--
Geoffrey Furnish http://dino.ph.utexas.edu/~furnish
UT Institute for Fusion Studies, fur...@dino.ph.utexas.edu 512-471-6147
MCC Experimental Systems Lab, fur...@mcc.com 512-338-3717
"Pushing back the boundary of inanity."
Mark Roseman
in heat, stems from some different approaches to object-oriented
programming. OO isn't new (it's been around since Simula 67), and
therefore has a few different viewpoints. Most of us are familiar
with the C++ style of OO, which Michael tried to preserve with
[incr Tcl]. David's OTcl takes a different approach, more based on
the OO viewpoint and style found in the Lisp community.
Since many people aren't familiar with some of the ways that the
features David is talking about can be used, I'd like to point to a
Web page at Xerox Parc talking about "Open Implementations" which is
an area that takes advantage of many of these types of features.
There are some discussions and papers available there.
http://www.parc.xerox.com/PARC/spl/eca/oi.html
Again, recognize that there is not one set of "universal reasons"
for adopting an OO paradigm, and that different systems do in fact
aim at different needs. There's no point judging one system by the
requirements generated from another system; instead, generate a set
of requirements for your own project, and see which system fits
them best.
Mark
--
Mark Roseman, Research Associate phone: (403) 220-3532 / 220-6087
Dept. of Computer Science fax: (403) 284-4707
University of Calgary email: ros...@cpsc.ucalgary.ca
Calgary, Alta CANADA T2N 1N4 http://www.cpsc.ucalgary.ca/~roseman
wi...@spooky.rwwa.com
>
>In article <3vgo87$o...@GRAPEVINE.LCS.MIT.EDU> "David J. Wetherall" <djw> writes:
>
>> From: "David J. Wetherall" <djw>
>> in OTcl you can do things like:
>>
>> add methods/instance variables to existing objects/classes
>> change the class of an existing instance
>> change the superclasses of an existing class
>> destroy/rename existing classes/objects
>>
>> itcl doesn't support these things, and that's the point,
>
>to imagine why I would want to use a language which supported this
>sort of programatic mele.
While I would like to see examples from djw showing why he things
those things are important, I certainly don't think any persons
ability to imagine a reason for using them is particulary important.
I often find myself lobbying for the addition of things even though I
don't have a specific use for them in mind; usually on
orthoganality/uniformity grounds. Suffice to say that the uses
generally (and quickly) come. (And the curses about non-uniformity
and non-orthoganality when I loose the battles.)
This is not a blanket excuse for featurism, but I think that
compelling arguments can be made even in the absense of examples.
-----------------------------------------------------------------------------
Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430 Net: wi...@rwwa.COM
R.W. Withrow Associates, 319 Lynnway Suite 201, Lynn MA 01901 USA
Alessandro Bollini
|>
|> Again, recognize that there is not one set of "universal reasons"
|> for adopting an OO paradigm, and that different systems do in fact
|> aim at different needs. There's no point judging one system by the
|> requirements generated from another system; instead, generate a set
|> of requirements for your own project, and see which system fits
|> them best.
Agree...
This is a good argument against pulling a particular OO extension
into the core. What Tcl really needs are general-purpose facilities
for building ad-hoc object systems. Namespaces and modular tracing
of commands and variables, to name a few, would make it quite easy
to adopt either class- or delegation-based paradigms.
Alessandro
--
Alessandro Bollini (bol...@ariadne.it)
Ariadne Engineering
Via Campeggi 13 - 27020 Casottole di Torre d'Isola (PV) - Italy
Rick Kramer
> >In article <3vgo87$o...@GRAPEVINE.LCS.MIT.EDU> "David J. Wetherall" <djw> writes:
> >
> >> From: "David J. Wetherall" <djw>
> >> in OTcl you can do things like:
> >>
> >> add methods/instance variables to existing objects/classes
> >> change the class of an existing instance
> >> change the superclasses of an existing class
> >> destroy/rename existing classes/objects
> >>
> >> itcl doesn't support these things, and that's the point,
> >
> >[...] I cannot begin
> >to imagine why I would want to use a language which supported this
> >sort of programatic mele.
>
> I often find myself lobbying for the addition of things even though I
> don't have a specific use for them in mind; usually on
> orthoganality/uniformity grounds. Suffice to say that the uses
> generally (and quickly) come. (And the curses about non-uniformity
> and non-orthoganality when I loose the battles.)
Many of the things that OO is good for you can fake in tcl. Because
you can so easily construct procedure names to call, you don't need a
lot of the flexibility that OO hiearchies give you.. (in terms of
overloading operators and virtual functions)
For example (since people seem to like examples so much). You can
create a set of operations for motif widgets.. Without specifying any
class declarations, you can use the Motif class name to identify
unique tcl proc's to call.. Just concatenate them.. So a generic
put_value for different classes of widgets could be:
<class>_put
The purpose of this could be to put a string (or set of strings) into
a widget.. You would have different procedures for textfields,
labels, pushbuttons, list widgets, etc. All you need is the widget to
know which procedure to call.. You could also use global arrays keyed
of widget id's & function names to store static info.. (as usual)
And so I think organization / interface specification / packaging code
are the primary reasons for using an OO extension. Since tcl lacks
the syntax and rigidity to do this well alone.
-rick
Michael Salmon
ros...@cpsc.ucalgary.ca (Mark Roseman) writes:
[...]
|> Since many people aren't familiar with some of the ways that the
|> features David is talking about can be used, I'd like to point to a
|> Web page at Xerox Parc talking about "Open Implementations" which is
|> an area that takes advantage of many of these types of features.
|> There are some discussions and papers available there.
|>
|> http://www.parc.xerox.com/PARC/spl/eca/oi.html
Are there any newsroups with discussions about "Open Implementations"?
--
© 1995 Michael Salmon
All opinions expressed in this article remain the property of
Michael Salmon. Permission is hereby granted for use in
followup articles, FAQ's and digests.
Jesse Abraham Rothstein
The puzzling behavior of the text widget tag bindings has been
giving me a headache for quite some time. Basically, I have
constructed a rather elaborate text widget, one section of which
prompts the user with a question and waits for an answer. This is
easy enough, but I would really like to be able to prevent the user
from clobbering the question and other text within the widget. That
is, I would like to keep it disabled everywhere outside of the user's
input tag. Well, I considered using an embedded window for input
rather than a tag, but I would like to allow for an arbitrarily long
answer while keeping the scrolling pretty. In any case, this would
all be easy enough to accomplish with an <Enter> and <Leave> binding
on my input tag, BUT (you knew there was a but) these bindings have
nothing to do with the location of the insert cursor and everything to
do with the location of the pointer. This is the puzzling behavior
which I mentioned above. Now, it's not puzzling because it's
undocumented (in fact, it is well-documented), but rather because I
can't really see the sense in it. In any case, to accomplish to some
degree the effect I desire, I've had to override a lot of bindings:
# switch bindtags order so that insert mark location is updated first
bindtags .t {_T Text .t . all}
bind .t <1> {+
if {[lsearch [.t tag names insert] entry] == -1} {
.t configure -state disabled
} else {
.t configure -state normal
}
}
bind .t <Key> {+
if {[lsearch [.t tag names insert] entry] == -1} {
t_dis
} else {
t_ins
}
}
bind _T <Delete> {
# are we deleting a selection?
if {[.t tag ranges sel] != {}} {
# if the selection is not entirely in entry, don't delete
if {[.t compare sel.first < entry.first]} {
.t tag remove sel 1.0 end
}
}
}
Now, similar bindings are necessary for <BackSpace>, <Control-h>,
<Meta-Delete>, <F20>, and probably a few more events I haven't gotten
to yet. So, basically I'm saying that this is a lot of hassle for a
relatively simple effect, which I am still unable to completely
achieve. I would be VERY happy and appreciative if someone would tell
me of an easier way. And, Gee, it sure would be nice if those <Enter>
and <Leave> tag bindings behaved more like a window. Thanks in advance...
--
Jesse Rothstein sle...@owlnet.rice.edu
Michael Altmann
class could not be modified after the class was defined.
THen I looked at Nautilus, whci provides a graphical view of Itcl
classes, and found that it allows you to change the definition of
a method in an existing class. I don't know how the author did
it or in what other undocumented ways you can change an Itcl class
after definition. Could Itcl or Nautilus authors clarify?
-----------
Michael Altmann
Box 511 UMHC
National Micropopulation Simulation Resource
Division of Health Computer Sciences
University of Minnesota
Minneapolis, MN 55455
email: Mic...@SIMVAX.LabMed.UMN.edu
http://www.nmsr.labmed.umn.edu
comp.simulation FAQ:
http://www.nmsr.labmed.umn.edu/~michael/dbase/comp-simulation.html
phone: (612)625-9938
fax: (612) 625-7166
--
Michael Altmann
Box 511 UMHC
National Micropopulation Simulation Resource
Division of Health Computer Sciences
University of Minnesota
Minneapolis, MN 55455
email: Mic...@SIMVAX.LabMed.UMN.edu
http://www.nmsr.labmed.umn.edu
comp.simulation FAQ:
http://www.nmsr.labmed.umn.edu/~michael/dbase/comp-simulation.html
phone: (612)625-9938
fax: (612) 625-7166
Michael J. McLennan
: >Carl D. Roth (ro...@cse.ucsc.edu) wrote:
: >: [incr tcl] is a good idea, but its class definitions are static
: >: (can't be changed) and it doesn't have an API (that I know of).
: >This is a common misconception about [incr Tcl] that I would like to
: >correct ... although [incr Tcl] has strong classes, it is not "static".
: >After all, it is sitting on a very dynamic interpreter. Attached
: >below is an [incr Tcl] class called "Object" which reproduces much
: >of the functionality in David Wetherall's OTCL package. Using this
: >class, you can create a generic itcl object and customize it to act
: >like a stack:
: it's not a misconception - your example is all smoke and mirrors michael.
Gee, I don't see what's so mysterious about it. I just implemented a
dynamic object system in about 50 lines of itcl code. Once the base
class "Object" is defined, anyone can treat that as a black box and
do dynamic object programming using itcl-1.5. Your otcl package goes
one step further and implements the same functionality in C code. But
as far as the concept goes, does the implementation really matter?
I showed that example to prove a point. People often criticism itcl
as being "static", and after further discussion, their argument boils
down to something like this. They want to have a class Record, for
example, with some data members:
itcl_class Record {
protected name "Joe Blow"
protected phone "555-blow"
protected email "jb...@foo.com"
...
}
But elsewhere in their program, they want to add some data members for
address, social security number, etc. You can have this kind of
flexibility quite easily in itcl--just use an array:
itcl_class Record {
protected info
constructor {name phone email} {
set info(name) $name
set info(phone) $phone
set info(email) $email
}
...
}
This gives you flexibility without violating the integrity of what a
"class" represents. The "Object" class that I posted takes this concept
one step further, managing code fragments as well as data members.
With all of this discussion, I do not mean to belittle the work that
you have accomplished. Your otcl package is clearly better than the
goofy 50-line "Object" class that I hacked up. You can be proud of
your work and the otcl package. But in generating enthusiasm for
your own package, I don't think you need to tear down itcl with
false claims.
Since otcl supports the dynamic object paradigm so well, I would invite
you to show more examples of where that paradigm excels. In my own
work, I have not seen the need for much flexibility beyond the example
shown above. Convince people (including me) why they need the extra
flexibility that otcl provides, and how the benefits of flexibility
outweigh the cost of losing structure.
Nat Pryce
>Since otcl supports the dynamic object paradigm so well, I would invite
>you to show more examples of where that paradigm excels. In my own
>work, I have not seen the need for much flexibility beyond the example
>shown above. Convince people (including me) why they need the extra
>flexibility that otcl provides, and how the benefits of flexibility
>outweigh the cost of losing structure.
I think Itcl and Otcl are both excellent packages. I have had more experience
with Itcl and have come up against problems with its static nature. That's not
to knock it, though, since in many situations, a static, class-based approach
leads to code which is easier to understand and maintain.
However, there's more to dynamic objects than your example of just adding new
members or methods. Certain dynamic situations can best be modelled by
changing an object's class after it has been created, particularly when
the object's role or capabilities change. One can model this by giving the
object a "capability" object which it delegates to (the State pattern);
however, this "capability" is really what classes are there to represent.
Therefore if the capabilities of an object are likely to change, it makes most
sense to model that by changing the class of the object.
My approach would be that one doesn't *have* to use all the dynamic features
of Otcl in every script; one can use it to build static class structures if
one wishes. However, the fact that more dynamic features are supported will
make things easier when they are needed. This approach is rather similar to
Tcl's procs: most scripts define a proc once but it is occasionally useful
to redefine a proc or command.
Cheers,
Nat.
--
+-------------------------------------------+---------------------------------+
| Name: Nat Pryce MEng ACGI | Mail: Department of Computing, |
| Email: n...@doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8934 (Direct Dial) | 180 Queen's Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
+-------------------------------------------+---------------------------------+
David J. Wetherall
>: >Carl D. Roth (ro...@cse.ucsc.edu) wrote:
>: >: [incr tcl] is a good idea, but its class definitions are static
>: >: (can't be changed) and it doesn't have an API (that I know of).
>
>: >This is a common misconception about [incr Tcl] that I would like to
>:
> it's not a misconception - your example is all smoke and mirrors michael.
>Gee, I don't see what's so mysterious about it. I just implemented a
>dynamic object system in about 50 lines of itcl code. Once the base
>class "Object" is defined, anyone can treat that as a black box and
>do dynamic object programming using itcl-1.5. Your otcl package goes
>one step further and implements the same functionality in C code. But
>as far as the concept goes, does the implementation really matter?
you missed the point. as i explained before, the example you dreamt up has
nothing to do with itcl. you're building a separate object system. and if you
followed your own line of thinking, then you'd end up using that tiny object
system written in tcl rather than an extension . . . pretty ironic.
>With all of this discussion, I do not mean to belittle the work that
>you have accomplished. Your otcl package is clearly better than the
>goofy 50-line "Object" class that I hacked up. You can be proud of
>your work and the otcl package. But in generating enthusiasm for
>your own package, I don't think you need to tear down itcl with
>false claims.
we might disagree on some things, but i don't think i've made any false
claims. if you do, then it's time to say exactly what they are.
also, i hope it's clear that i'm not comparing otcl with your example.
i'm comparing otcl with itcl.
>Since otcl supports the dynamic object paradigm so well, I would invite
>you to show more examples of where that paradigm excels. In my own
>work, I have not seen the need for much flexibility beyond the example
>shown above. Convince people (including me) why they need the extra
>flexibility that otcl provides, and how the benefits of flexibility
>outweigh the cost of losing structure.
>
>--Michael
if you really want me to argue in favor of otcl, then i'd start here:
an object extension for tcl should be just that - a small addition that
gives you object-oriented programming facilities with a minimum
of fuss. it shouldn't impose a complete programming paradigm, it shouldn't
come with the kitchen sink, and it shouldn't fool with the core. otcl
doesn't do these things. itcl does - itcl1.5 is at least four times as large
as otcl, and itcl2.0 will have even more "features" plus hack the core.
don't think that you get less bang for yor buck with otcl though. it's
compact because it reuses the tcl library wherever possible. otcl provides
a more powerful object system than itcl. it has a real class system, letting
you manipulate classes as well as objects. it has a more general inheritance
model, supporting real multiple inheritance with automatic combination of
methods. it's far more flexible, letting you redefine system-provided methods
as easily as user provided methods.
and don't think that you can't write large programs in otcl because it's
dynamic. lisp/clos is pretty dynamic, and supports some of the most complex
programs around.
cheers,
djw
Larry W. Virden:
Since many folk don't know what criteria to use to spec out requirements
for an OO extension, it does however make sense for you experts to
accumulate the various criteria that might be used with comments on
how each of the OO extensions address the issues so that folk can then
pick and choose what they need.:s My new WWW home is coming...
Michael J. McLennan
: >dynamic object system in about 50 lines of itcl code. Once the base
: >class "Object" is defined, anyone can treat that as a black box and
: >do dynamic object programming using itcl-1.5. Your otcl package goes
: >one step further and implements the same functionality in C code. But
: >as far as the concept goes, does the implementation really matter?
: you missed the point. as i explained before, the example you dreamt up has
: nothing to do with itcl. you're building a separate object system.
No, you missed the point. Many people criticize C++ for being "too static"
without understanding the ways that it can be used to do dynamic things.
I think the same thing is happening here. It is true that [incr Tcl]
is far less dynamic than otcl, but for a reason. The vast majority of
my code benefits from the structure that [incr Tcl] provides. For the
once-in-a-while case where I need a little extra flexibility, [incr Tcl]
supports that too.
: > But in generating enthusiasm for
: >your own package, I don't think you need to tear down itcl with
: >false claims.
: we might disagree on some things, but i don't think i've made any false
: claims. if you do, then it's time to say exactly what they are.
Here are a few:
David J. Wetherall (djw) wrote:
> i can't imagine how itcl could be less dynamically extensible,
> given that it's interpreted to begin with.
David J. Wetherall (djw) wrote:
> no, many people believe itcl is "static" because it is - people
> don't even know how to get rid of a class once it's defined!
You can delete a class and all of its associated objects using the
"itcl_unload" or "itcl_reload" procedures. You can autoload classes,
create new classes on the fly, and do interactive development with
[incr Tcl].
But I think the biggest claim that you made is "otcl is better".
I think what you meant is that otcl is better at supporting the dynamic
object paradigm. I certainly agree with this, and again congratulate
you on your work. But I am still wondering why I need the dynamic
object paradigm, and I would like to see some examples to clarify this.
Since you have used otcl in your own work, you must have a few examples
sitting around that show, for example,
1) Why you need to change the class of an object on the fly.
2) Why you need to change an inheritance hierarchy on the fly.
3) Why you need to remove data members or member functions
from an object.
None of the examples in your paper show this.
On the other hand, when you said "otcl is better", you may have meant
that it is a better package. If this is the case, then you need to
answer the questions that Geoffrey Furnish posed:
1) How does otcl support mega-widgets?
[incr Tcl] provides the [incr Tk] framework and the [incr Widgets]
set of predefined widgets.
2) In otcl, everything is public. Any client can reach into an
object and directly manipulate data members and member functions.
How then does otcl support encapsulation?
[incr Tcl] provides public/protected/private distinctions for
all data members and member functions.
Recall that at the recent Tcl/Tk Workshop, John Ousterhout put up a
list of new features for people to vote on. The top two requested
features where mega-widgets and namespaces. [incr Tcl] supports both
of these. In fact, it integrates the namespace facility directly into
the Tcl core where it belongs. (This is why--as you put it--I "fooled
with the core".) If otcl is a better package, how do you support these
important features?
Again, it is foolish for us to argue which package is better. People
will decide for themselves. But if you decide to continue this thread,
please show us why the dynamic object paradigm is better, and provide
some concrete examples to back up your arguments.
Carl D. Roth
In article <DCy8B...@nntpa.cb.att.com> m...@mhcnet.att.com (Michael
J. McLennan) writes:
Michael> The vast majority of my code benefits from the structure that
Michael> [incr Tcl] provides. For the once-in-a-while case where I
Michael> need a little extra flexibility, [incr Tcl] supports that
Michael> too.
I don't see what the structure buys you. Putting all of your members
in one place might enhance first-time readability, but unless you go
the full distance and provide exportable interfaces (like Objective C)
you aren't really improving the development environment that much. I
don't want to have to put all my members in the same file.
Michael> You can delete a class and all of its associated objects
Michael> using the "itcl_unload" or "itcl_reload" procedures. You can
Michael> autoload classes, create new classes on the fly, and do
Michael> interactive development with [incr Tcl].
I don't consider unloading and reloading to be 'interactive'. You're
required to re-source too much code during an interactive editing
cycle. If I want to redefine a class interactively, I don't want to
delete all of the old instances as a side effect. OTcl simply demotes
the affected objects. This is big debugging aid.
Michael> But I think the biggest claim that you made is "otcl is
Michael> better". I think what you meant is that otcl is better at
Michael> supporting the dynamic object paradigm. I certainly agree
Michael> with this, and again congratulate you on your work. But I am
Michael> still wondering why I need the dynamic object paradigm, and I
Michael> would like to see some examples to clarify this. Since you
Michael> have used otcl in your own work, you must have a few examples
Michael> sitting around that show, for example,
Michael> 1) Why you need to change the class of an object on the fly.
Interfacing the OO system to a C/C++ API requires dynamic class
promotion/demotion. It's used to exploit the class hierarchy,
i.e. "demote this object and let the parent class delete it". This
lets the OTcl framework do as much of the housekeeping as possible.
Michael> 2) Why you need to change an inheritance hierarchy on the
Michael> fly.
For interactive reasons. Adding and removing range checking or
authentication mechanisms, for instance. Or, say, an object is
physically exported, as in Objective C. It's base class would
fundamentally change to reflect the new underlying access methods.
Michael> 3) Why you need to remove data members or member
Michael> functions from an object.
For code editing.
Michael> None of the examples in your paper show this.
Correct. I think Otcl really needs a man page (especially for its API).
Michael> 2) In otcl, everything is public. Any client can reach into
Michael> an object and directly manipulate data members and member
Michael> functions. How then does otcl support encapsulation?
How can you tout encapsulation in an interpreted language? If I could
re-source a class definition, why would I let 'protected' members stop
me?
Michael> [incr Tcl] provides public/protected/private distinctions for
Michael> all data members and member functions.
The only *useful* technique I would like, that neither itcl nor Otcl
provides, is a way to *suspend* the interactivity for parts of the
name space--that is, declaring classes once and then making them
read-only. Only then can you ensure against partial or wholesale
modification of the class behavior.
I think the point that I am trying to make in this discussion is:
Applications don't need dynamic objects,
but developers do.
-- Carl <http://sctest.cse.ucsc.edu/roth/>
David J. Wetherall
No, you missed the point. Many people criticize C++ for being "too static"
without understanding the ways that it can be used to do dynamic things.
I think the same thing is happening here ...
so you mean itcl is dynamic in the same sense that c++ is dynamic? i
guess i could implement an otcl interpreter in c++ ... but that would
hardly be a cogent argument for c++ being dynamically extensible. i
think your itcl argument is in the same vein.
: we might disagree on some things, but i don't think i've made any false
: claims. if you do, then it's time to say exactly what they are.
Here are a few:
David J. Wetherall (djw) wrote:
> i can't imagine how itcl could be less dynamically extensible,
> given that it's interpreted to begin with.
David J. Wetherall (djw) wrote:
> no, many people believe itcl is "static" because it is - people
> don't even know how to get rid of a class once it's defined!
i stand by those comments.
But I think the biggest claim that you made is "otcl is better".
I think what you meant is that otcl is better at supporting the dynamic
object paradigm. I certainly agree with this, and again congratulate
you on your work. But I am still wondering why I need the dynamic
object paradigm, and I would like to see some examples to clarify this.
Since you have used otcl in your own work, you must have a few examples
sitting around that show, for example,
1) Why you need to change the class of an object on the fly.
2) Why you need to change an inheritance hierarchy on the fly.
3) Why you need to remove data members or member functions
from an object.
None of the examples in your paper show this.
thanks for agreeing that otcl is better for dynamically extending
stuff. but i meant that otcl was a better object system. i think the
"prove to me by example why i need to dynamically extend things" line
is a bit of a red herring. beyond the observation that i find it
useful but you don't, remember that tcl is a dynamically extensible
language. it seems a gratuitous design decision to make an oo
extension that isn't. others have also commented on its uses.
On the other hand, when you said "otcl is better", you may have meant
that it is a better package. If this is the case, then you need to
answer the questions that Geoffrey Furnish posed:
i advanced an argument in favor of otcl last post, with some reasons
why it was more powerful. feel free to respond.
1) How does otcl support mega-widgets?
[incr Tcl] provides the [incr Tk] framework and the [incr Widgets]
set of predefined widgets.
megawidgets are an application for an oo extension. you can go right
ahead and make them yourself, in much the same way that people do in
itcl; i don't think there's anything especially deep there. i do agree
that a standard library of convenience routines and classes would be
useful though.
2) In otcl, everything is public. Any client can reach into an
object and directly manipulate data members and member functions.
How then does otcl support encapsulation?
[incr Tcl] provides public/protected/private distinctions for
all data members and member functions.
otcl instance variables and methods don't pollute the global
namespace. there's no problem. if you are talking about
sealing/protection in an interpreted language, then your faith is
misplaced: you can get at itcl private variables quite easily by, for
example, redefining the body of a method to get or set the private
variable's value. also recall that tcl doesn't support
sealing/protection.
Recall that at the recent Tcl/Tk Workshop, John Ousterhout put up a
list of new features for people to vote on. The top two requested
features where mega-widgets and namespaces. [incr Tcl] supports both
of these. In fact, it integrates the namespace facility directly into
the Tcl core where it belongs. (This is why--as you put it--I "fooled
with the core".) If otcl is a better package, how do you support these
important features?
namespaces are useful for all tcl programming; they're not part of an
oo extension. i chose to wait until they are in tcl, rather than
inventing my own scheme. after all, we have survived this long. again,
i suggest that you separate your namespace extension from the oo bit
so it can be useful to other people.
also, i wouldn't be too happy about fooling with the core. most people
avoid it if they can, since it makes an extension more fragile and
less portable. for example, otcl might survive a new tcl release
unchanged, while itcl cannot.
Again, it is foolish for us to argue which package is better. People
will decide for themselves. But if you decide to continue this thread,
please show us why the dynamic object paradigm is better, and provide
some concrete examples to back up your arguments.
cheers,
djw
Mark A Harrison
: In article <DCy8B...@nntpa.cb.att.com> m...@mhcnet.att.com (Michael J. McLennan) writes:
: 1) Why you need to change the class of an object on the fly.
: 2) Why you need to change an inheritance hierarchy on the fly.
: 3) Why you need to remove data members or member functions
: from an object.
: i think the
: "prove to me by example why i need to dynamically extend things" line
: is a bit of a red herring. beyond the observation that i find it
: useful but you don't,
Unfortunately, "I find it useful but you don't" isn't very enlightening.
Some tangible examples would help to get your point across -- how are
programs "better" when you use these features, and "better" in what
context?
--
Mark Harrison http://jasper.ora.com/mh/
Lee Hounshell
>> 2) Why you need to change an inheritance hierarchy on the fly.
>> 3) Why you need to remove data members or member functions
>> from an object.
I can think of one instance wher the otcl approach might excell.
In Genetic Programming and Neural Networks it is often necessary to
maintain and operate with thousands (millions?) of objects.
Often these objects may change, as they undergo "crossover"
or "combination" with other objects. The Otcl approach might in fact
be a revolutionary new language for building such systems. It would
allow "crossover" in GA's by creating a new class from parts of the classes
of two or more other GA objects. A similar approach could be used
for creating new neuron-controllers from combinations of other neuron
objects and/or classes in a neural network.
Hmmmm... I was one of the original guys who couldn't understand
how this might be useful. Looks like I may have answered my
own questions, and possibly found an important nitch for otcl...
What do others think of this idea?
-Lee Hounshell
l...@tcs.com
George A. Howlett
: In article <DCy8B...@nntpa.cb.att.com> m...@mhcnet.att.com (Michael J.
McLennan) writes:
: But I think the biggest claim that you made is "otcl is better".
: I think what you meant is that otcl is better at supporting the dynamic
: object paradigm. I certainly agree with this, and again congratulate
: you on your work. But I am still wondering why I need the dynamic
: object paradigm, and I would like to see some examples to clarify this.
: Since you have used otcl in your own work, you must have a few examples
: sitting around that show, for example,
: 1) Why you need to change the class of an object on the fly.
: 2) Why you need to change an inheritance hierarchy on the fly.
: 3) Why you need to remove data members or member functions
: from an object.
: None of the examples in your paper show this.
: thanks for agreeing that otcl is better for dynamically extending
: stuff. but i meant that otcl was a better object system. i think the
: "prove to me by example why i need to dynamically extend things" line
: is a bit of a red herring. beyond the observation that i find it
: useful but you don't, remember that tcl is a dynamically extensible
: language. it seems a gratuitous design decision to make an oo
: extension that isn't. others have also commented on its uses.
: On the other hand, when you said "otcl is better", you may have meant
: that it is a better package. If this is the case, then you need to
: answer the questions that Geoffrey Furnish posed:
: i advanced an argument in favor of otcl last post, with some reasons
: why it was more powerful. feel free to respond.
How is providing examples a "red herring"? For starters, it would let
*me* judge for myself whether I think a particular paradigm is useful
or not.
I've read you paper and your recent posts. But I'm left with the same
question. Where are infinitely mutable objects useful? Can you
demonstrate an application with code examples? That way, I can
compare it to how I might try to solve the same problem with other
techniques. This doesn't have to be in any way adversarial. I would
just like to understand your arguments better.
I thank Carl Roth for coming close to actually providing an example.
I think he was suggesting dynamic objects would be useful in
interactive development environment. I may not necessarily agree with
all of his conclusions, but he's helped me a lot further along in
understanding some of the issues.
Language issues are abstract and usually subjective. So making
sweeping statements will be unpersuasive. Which is why providing
concrete examples is all the more important.
: Recall that at the recent Tcl/Tk Workshop, John Ousterhout put up a
: list of new features for people to vote on. The top two requested
: features where mega-widgets and namespaces. [incr Tcl] supports both
: of these. In fact, it integrates the namespace facility directly into
: the Tcl core where it belongs. (This is why--as you put it--I "fooled
: with the core".) If otcl is a better package, how do you support these
: important features?
: namespaces are useful for all tcl programming; they're not part of an
: oo extension. i chose to wait until they are in tcl, rather than
: inventing my own scheme. after all, we have survived this long. again,
: i suggest that you separate your namespace extension from the oo bit
: so it can be useful to other people.
I don't think waiting for namespaces to be put into the Tcl core is a
viable alternative. It's no small, surgical change. If it happens at
all, I wouldn't expect it until long after current projects like
dynamic loading, Tk Window and Mac ports, Tcl compiler, et al. are all
completed. As far as surviving, I already know what it's like without
namespaces: no packages, no megawidgets, abuse of global arrays, ...
Let's be honest. All the work Dr. McLennan has done in adding namespaces
to [incr Tcl] is a big win.
: also, i wouldn't be too happy about fooling with the core. most people
: avoid it if they can, since it makes an extension more fragile and
: less portable. for example, otcl might survive a new tcl release
: unchanged, while itcl cannot.
The key phrase is "if it can be avoided". Namespaces can't. Again,
what's the alternative? And I better off *without* namespaces? I
don't think so.
--gah
Martin Andrews
There are two primary reasons I prefer OTcl. First, OTcl is small and
elegant. This makes it easier to include OTcl in my applications, and if
I didn't care about elegance I would probably be using Perl. Secondly,
OTcl is available now with a C API (rough, but it is there). Dr. McLennan
has promised a C API and other nifty features for [incr Tcl] 2.0, but it
is not available now and I have not heard when it will.
As far as dynamic class structures go - I still haven't made use of them
(but I do see their use in a GUI builder/editor as was previously
mentioned). I have been taking advantage of the ability to derive
new class types though. In a megawidget package I am working on,
I derive a new class "Megawidget". Classes created with megawidget
can define new instance methods that are forwarded to child widgets.
Here is a short (kind of silly) example:
Megawidget create Defaultbutton -superclass Frame
Defaultbutton instproc init {args} {
eval $self next -relief raised -bd 1 $args
button $self.btn
pack $self.btn -padx 2m -pady 2m
}
Defaultbutton instpass invoke btn
Defaultbutton instpass flash btn
Without the ability to create new class types, I would have to do
something like:
Defaultbutton instproc invoke {args} {
eval $self next $args
}
which is inefficient and cumbersome.
Regarding namespaces:
George A. Howlett (ghow...@fast.net) wrote:
: The key phrase is "if it can be avoided". Namespaces can't. Again,
: what's the alternative? And I better off *without* namespaces? I
: don't think so.
Now that I am using OTcl, I don't find a strong need for namespaces.
Methods and instance variables seem to do the trick. Admittedly, OTcl
does not give transparent access to methods and instance variables with
a method - you must use:
$self myMethod
instead of:
myMethod
and you must declare instance variables used within a method:
$self instvar myvar1 myvar2
set myvar1 $myvar2
instead of just:
set myvar1 $myvar2
Some may baulk at these requirements - but I find it creates more
readable code. Like the "global" Tcl command - it makes it easy
to understand references within a procedure. I can easily differentiate
global, object, and local references within a method.
I hope I have generated more light than heat.
Martin
--
Martin Andrews and...@ccfadm.eeg.ccf.org
Section of Neurological Computing Phone (216)444-7485
Cleveland Clinic Foundation Fax (216)445-6617
Horace A. Vallas
>> 1) Why you need to change the class of an object on the fly.
>> 2) Why you need to change an inheritance hierarchy on the fly.
>> 3) Why you need to remove data members or member functions
>> from an object.
For 1 & 2 (and maybe 3), an example might be a data-import application
in which there was a requirement to allow the data provider to describe
(on the fly - meaning in the data stream) his/her own private
objects is used (perhaps based on one or more existing classes).
Assuming a set of fundemental classes (like for basic data types), then
higher level "provider-defined" models could be imported. You
might not know how to perform additional application-specific processing
of these data objects, but you could import and hold/store them
for later export.
Consider the requirements of...
1) the American Petroleum Institute's "Digital Log Interchange"
DLIS-RP66
2) the ISO standard "Express" (sorry - forgot its number)
--
ooba ooba,
Horace
===============================================================
Horace A. Vallas, Jr. http://www.neosoft.com/~hav/home.html
hav.Software http://www.neosoft.com/~hav
P.O. Box 354 h...@neosoft.com
Richmond, Tx. 77406-0354 (713) 341-5035
=== === === === === === === === === === ===
The probability of life originating from accident is comparable
to the probability of the Unabridged Dictionary resulting from
an explosion in a printing factory. - Prof. Edwin Conklin
===============================================================
Hadar Pedhazur
>> 1) Why you need to change the class of an object on the fly.
>> 2) Why you need to change an inheritance hierarchy on the fly.
>> 3) Why you need to remove data members or member functions
>> from an object.
I have been a "lurker" on this group for about 6 months, and this is my first
post. Let me state up front that I have never seen itcl or Otcl, so my
thoughts here are a generic response to the above questions, and in no way
relate to the actual capabilities of the two products which started this
discussion.
For the past year, I have been Beta Testing a product called Objective-Tcl
(ObjTcl) from TipTop Software. I believe that they presented a paper at the
recent Tcl workshop in Canada. Anyway, the product was finally released this
week, and I feel unshackled to actually make some comments about it, and the
specific issues raised in this thread.
Briefly, ObjTcl is a combination of a full Objective-C style interpreter,
and, it can be emebedded within an Objective-C program, and is 100%
transparent to the runtime. In other words, one can not tell whether a class,
method, etc., is written in ObjC or ObjTcl.
An example of the desire (hard to ever qualify something as a need, since
presumably you could redesign the app to achieve the same functionality
in a different way :-)) for changing object definitions on the fly would be
the following:
I have an app where I provide a default implementation of a method to
determine a particular UI for some calculation results. In this app, the
USER (or me if the user prefers not to write ObjTcl) may write a Category
(an Objective-C construct whereby one may add or override methods in another
class), which redefines the behavior of the default UI method. They can
also couple that with an override of the calclulations themselves and end
up using my app as a framework with them providing the custom parts. This
has worked very well for us.
There are other techniques which we have employed very successfully
in our group that are different from the above, but I hope that I have not
overstepped my welcome on my first post to this group, so I'll end this
here. I would like to stress that this is neither a plug for ObjTcl (which
I fully intend to plug to the NeXT community in a few minutes in
comp.sys.next.programmer and comp.lang.objective-c) and it is certainly not
any form of statement about itcl or Otcl.
--------------
Hadar Pedhazur
Global Equity Derivatives
Union Bank of Switzerland (UBS)
Mark Roseman
Hadar Pedhazur <ubs!ha...@uunet.uu.net> wrote:
>Briefly, ObjTcl is a combination of a full Objective-C style interpreter,
>and, it can be emebedded within an Objective-C program, and is 100%
>transparent to the runtime. In other words, one can not tell whether a class,
>method, etc., is written in ObjC or ObjTcl.
my reaction to objective tcl (and one i heard from a few people) was
definitely "nice package, but who cares?". i.e. if you're running a
next machine great, but for the rest of us its a non-starter.
(to repeat, i liked it, so don't flame me)
--
Mark Roseman, Research Associate phone: (403) 220-3532 / 220-7259
Cimarron Taylor
| David J. Wetherall (d...@savory.savory.lcs.mit.edu) wrote:
| : In article <DCy8B...@nntpa.cb.att.com> m...@mhcnet.att.com (Michael J. McLennan) writes:
| : 2) Why you need to change an inheritance hierarchy on the fly.
| : 3) Why you need to remove data members or member functions
| : from an object.
|
| : "prove to me by example why i need to dynamically extend things" line
| : is a bit of a red herring. beyond the observation that i find it
| : useful but you don't,
|
| Some tangible examples would help to get your point across -- how are
| programs "better" when you use these features, and "better" in what
| context?
| --
| Mark Harrison http://jasper.ora.com/mh/
When you are implementing a system which its own form of dynamic
extension, it is often useful to leverage the extensibility of
the implementation language.
I find this particularly helpful when I am in the experimentation
phase of a project and want to avoid developing infrastructure.
Once I have a better idea of the kind of extensibility I want to
provide, then I re-examine the issue of how much extensibility is
needed in the language. Early in a project I want an otcl approach
and later on I might itcl one.
switch $opinion {
professional {
I doubt adding a full object system to Tcl is a good idea. It
will make a simple and easy to use tool more complex and make
the learning, teaching and support of Tcl harder as more and
more Tcl code is developed. If done carelessly, it will make
the chance of re-implementing Tcl code in a lower level language
like C difficult or impossible.
}
soapbox {
Already there are several nice looking Tcl utilities I can't
use together because they all require different object systems
which all have their quirks. As a developer of code which is
intended to be extended by others, I make a point of avoiding
these systems as much as possible because I don't want to
require others who will need to modify or improve my code
to learn a new object system.
Most the programs I have written only really need procedure
and variable namespaces. Having implemented three variations
of namespaces on separate occasions (the varframe, defclass
and package extensions), and having seen several others
independently do this, I know this is a trivial task.
I really wish John O. would just pick a namespace solution and
add it to the Tcl core so we could all stop re-inventing the
Tcl object wheel.
}
hacker {
Developing code with Tcl is fast, fun and stimulating. There
are a lot of neat and innovative ideas in all these Tcl
extensions, which ideally will encourage rather than discourage
the development of neat and innovative applications which solve
new problems in new ways. When the question is not "why do you
need to do XXX," but rather, "if you had XXX, what really cool
things could you with it," you want to work in as flexible an
environment you can find. For me, this environment is usually
Tcl/Tk.
}
}
Cimarron Taylor
cima...@acgeas.com
Tako Schotanus
>There are other techniques which we have employed very successfully
>in our group that are different from the above, but I hope that I have not
>overstepped my welcome on my first post to this group, so I'll end this
>here.
No, I think you rather UNDERstepped it.... You forgot to tell where to get
any information about ObjTcl!!! It sounds like something I'd *really* love
to use. I'm currently using [incr Tcl] for a project but we've hit upon
a performance-problem. So we were looking into ways of coding part in C++,
but Otcl (non-MIT) is just a bit too restrictive (it's a real pain that
you can't access attributes from superclasses written in C++. Yes, people
keep telling me it's better that way, I don't care, I've done it now and
I'm not going to change it without looking at all the alternatives! ;) and
I can't say how Otcl (MIT) would fit the bill seeing that it's got only
two pages of documentation, none of which talk about any C++-binding (and
forgetting the fact that it's syntax is quite unlike [incr Tcl]'s and in
my opinion quite un-Tcl like). So maybe you can understand that I'm quite
interested in getting to know more about ObjTcl, I hope you can help me...
NB: People also keep telling me "the next version of [incr Tcl] will have
support for C++!", but I've been hearing that now for months and there's
no indication that it's going to appear any time soon, nor has there been any
indication of what kind of anhancements to expect. I'm trying to earn money
here so I'm sorry if I seem a tad impatient ;)
> I would like to stress that this is neither a plug for ObjTcl (which
>I fully intend to plug to the NeXT community in a few minutes in
>comp.sys.next.programmer and comp.lang.objective-c) and it is certainly not
>any form of statement about itcl or Otcl.
- Tako
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Tako Schotanus, van Hasseltlaan 352, 2625 HZ, Delft, The Netherlands _/
_/ work: Lange Kleiweg 5, 2288 GH, Rijswijk, NL, tel: +31-15-842393 _/
_/ E-mail: s...@bouw.tno.nl - URL: http://huizen.dds.nl/~quintess _/
_/ Never let a dictator rule with peace; let peace rule like a dictator _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Tako Schotanus
>
>In article <40iegk$p...@ns2.ny.ubs.com>,
>Hadar Pedhazur <ubs!ha...@uunet.uu.net> wrote:
>>Briefly, ObjTcl is a combination of a full Objective-C style interpreter,
>>and, it can be emebedded within an Objective-C program, and is 100%
>>transparent to the runtime. In other words, one can not tell whether a class,
>>method, etc., is written in ObjC or ObjTcl.
>
>my reaction to objective tcl (and one i heard from a few people) was
>definitely "nice package, but who cares?". i.e. if you're running a
>next machine great, but for the rest of us its a non-starter.
>
>(to repeat, i liked it, so don't flame me)
I hope this doesn't sound like a flame ;)
But why is it a non-starter for non-NeXt owners?? I have a Objective-C
compiler right here for my SunOS-machine (as will anybody else that uses
GCC), so unless it's because you need some specific C++ stuff that you've
already laying about I see no reason why you couldn't use ObjTcl.
Please tell me if *you* do...
Julian Brown
otcl.
You people are arguing about some very religious aspects of object
technology. But let us first discuss some practical aspects of the
two programs.
First and foremost otcl is lightweight, whereas [incr tcl] is more
complete (IMHO). I/We (as I am the lead) chose otcl for that reason alone.
Our company sells a product that is largely based on tcl/tk. We needed to
increase the capabilities of our product so we decided OO was the best
approach. We wrote our program in [incr tcl], the code was certainly
clean and we felt good about our work. Until we started doing metrics.
Our old program with a tcl interpreter (before we rewrote it in [incr tcl])
would typically add 400-600k to our data segment. Startup time on our
product was 3-4 seconds (which we thought was appalling). After we rewrote
the program in [incr tcl] without giving it new capabilities the data
segment often pushed 1.2 megabytes and startup time was about 6-7 seconds.
We later determined that the problem was due to the fact that [incr tcl]
uses a different interpretter for each class/object (I am not sure which)
and each interpretter was autoloading a lot of duplicative code. As a
result we dropped the project altogether as impractical with [incr tcl].
About a month ago we discovered otcl. I downloaded it and decided
to retry our project. I used the [incr tcl] code as a template and
translated the code from [incr tcl]. The code was faster and leaner than
our original tcl code. The metrics are approximately 100-200k and startup
times are 1-2 seconds. Using otcl over tcl with a clean design we improved
our performance over our original tcl code haphazardly designed by a factor
of 2 in both speed and memory. Whereas [incr tcl] with the same design
doubled our requirements, therefore [incr tcl] is 4 times more massive than
otcl.
Now let us keep in mind what the purpose of tcl/tk is, lightweight solutions
to problems. Tcl/Tk is not the tool to build skyscrapers but to solve the
nagging everyday problems we encounter. Now I will admit our program needs
to be resource conscious as there will be many copies of our program running
on a single cpu, whereas others are not concerned about those things. Which
brings me back to my original statement, otcl is a lightweight tool whereas
[incr tcl] is more complete.
Now the problems we encountered with [incr tcl] will be addressed in future
releases, as we had email discussions with the author. But the author of
[incr tcl] had no idea when those problems could be addressed.
Send all flames to ga...@microsoft.com
Julian Brown __ ___ ___
Pro\Sim Corp. __ / /_ __/ (_)__ ____ / _ )_______ _ _____
Houston, Tx. U.S.A. / /_/ / // / / / _ `/ _ \ / _ / __/ _ \ |/|/ / _ \
jul...@prosim.com \____/\_,_/_/_/\_,_/_//_/ /____/_/ \___/__,__/_//_/
http://www.neosoft.com/~prosim/PinQuik.html
--
Julian Brown __ ___ ___
Pro\Sim Corp. __ / /_ __/ (_)__ ____ / _ )_______ _ _____
Houston, Tx. U.S.A. / /_/ / // / / / _ `/ _ \ / _ / __/ _ \ |/|/ / _ \
jul...@prosim.com \____/\_,_/_/_/\_,_/_//_/ /____/_/ \___/__,__/_//_/
Martin Andrews
: [incr Tcl] is *significantly* faster than OTcl. Method dispatch
: is typically in the range 2x-4x faster, and object creation
: can be more than 10x faster. The performance gap gets wider
: with increasing complexity (increasing levels of inheritance).
You figures seem plausible - but I think that OTcl is capable of being
much faster than it is now. Foremost - the latest version of OTcl
(version 0.95) has the "create" and "init" methods written in Tcl -
I assume David did this so that he could rapidly try out a new construction
system introduced in this release. There is no reason they could not
be written in Tcl. Secondly, OTcl does no method caching. While OTcl's
dynamic nature will make caching tricky - it should be possible to
design a scheme that would work well for applications that do not
make great use of the dynamic features (admittedly, I am hand waving
here).
Anyway - my point is that OTcl is not currently tuned for performance.
Which version of [incr Tcl] were you using?
George A. Howlett
>Anyway - my point is that OTcl is not currently tuned for performance.
When's the release date for this "tuned" version?
BTW. It seems like this is another good reason *not* to make bald-faced
assertions that "mine is better".
--gah
Michael Altmann
change a class after it is created. During program development, it
would certainly be nice to fix bugs or improve behavior of the system
by changing the definition of a method (and less often adding methods
or attributes.) Of course I can edit my itcl file and re source it
but then I have to recreate the state of the program I am debugging.
I suspect there is some undocumented way to do this in itcl because Nautilus
does it. Until someone tells me what it is I fall back on code like
itcl_class myClass {
common foo_body {puts $i; return 4}
protected i 6
method foo {} {
return [eval $foo_body]
}
}
Here I can change foo_body and change the behavior of all objects immediately.
Once I settle on the right behavior I can move the definition into foo itself.
Another reason to be able to change classes it because I would like to make a
graphical programming environment in which a user could create a class
diagrammatically and then create instances of it.
I still feel that the biggest problem with itcl (and all Tcl object
systems as far as I know) is that instance variables are not global
and are therefore unusable as things like -textvariable s.
BTW, I have used itcl for a year, but have only looked at Otcl.
Carl D. Roth
Michael> [incr Tcl] is *significantly* faster than OTcl. Method
Michael> dispatch is typically in the range 2x-4x faster, and object
Michael> creation can be more than 10x faster. The performance gap
Michael> gets wider with increasing complexity (increasing levels of
Michael> inheritance).
You could make the same point by comparing itcl and a suitably more
static and restrictive competitor: C++. Using tcl in any application
involves a tradeoff between what can be scripted and what cannot. I
don't think the example you showed pushes that boundary far enough to
make me switch OO systems. I would *never* create 1000 objects, for
instance.
-- Carl
David J. Wetherall
In article <DDBEH...@nntpa.cb.att.com> m...@mhcnet.att.com (Michael J. McLennan) writes:
> To bring this discussion back to a technical level, I grabbed the latest
> release of OTcl and fiddled around with it. I found one critical
> difference between these two object systems:
>
>
> [incr Tcl] is *significantly* faster than OTcl. Method dispatch
> is typically in the range 2x-4x faster, and object creation
> can be more than 10x faster. The performance gap gets wider
> with increasing complexity (increasing levels of inheritance).
the numbers are interesting, but i don't think your conclusions
follow. the only real user we've heard from (julian brown) found that
translating his app to otcl improved performance by a factor of 2-4
because of its lightweight implementation. to emphasize that you
should take benchmarks with a grain of salt, consider code where class
creation is stressed: you'll fine otcl faster by a factor of 10.
> Since very few real-life applications have methods with null bodies,
> I benchmarked some non-trivial examples. I didn't try to cook up any
> special examples.
methods with empty bodies aren't meant to be realistic, they're meant
to stress dispatch. your examples have simple methods and are
essentially reporting on dispatch, though it sounds like you didn't
intend for this.
> =================================================================
> TEST [incr Tcl] OTcl Relative [incr Tcl]
> CASE (microsec) (microsec) performance*
> -----------------------------------------------------------------
> counter 574 858 1.5x
>
> stack
> put 3567 4030 1.1x
> get 6898 7242 1.0x
>
> safestack
> create 1570 20221 12.9x
> put 4308 8779 2.0x
> get 7907 11807 1.5x
> destroy 1571 4610 2.9x
>
> toaster
> create 10305 46476 4.5x
> toast 10138 30302 3.0x
> clean 5374 17567 3.3x
> delete 12694 20522 1.6x
> -----------------------------------------------------------------
> *Relative performance is defined as the ratio of OTcl execution
> time to [incr Tcl] execution time
martin was right, the two largest numbers are directly attributable to
system methods written in tcl instead of c. i thought it was kind of
cool writing them in tcl (it's amazing what you can do), but i've
changed them back to c in the name of "performance", so that the 12.9
and 4.5 entries both come in under 3.
that still leaves itcl method dispatch faster for now. i think there
are several reasons for this:
-otcl keeps at arms length from the interpreter (redispatching via
self) for better implementation modularity/portability
-otcl is doing more for you (try renaming an itcl object or class and
see if the system keeps track of it)
-otcl isn't tuned (its compact, without much caching in the dispatch
until we have a better feel for what should be optimized and what
should be left alone)
-itcl is trading worst-case quadratic memory usage for dispatch speed
(tables of all possible dispatches are precomputed)
> It is important to recognize the cost of a dynamic system. If you
> need to create 1000 SafeStack objects, you will wait 20 seconds
> to do it with OTcl, and only 1.5 seconds with [incr Tcl]. Granted,
> you may not need to create 1000 simple objects like this, but you
> may need to create hundreds of complex objects. With mega-widgets,
> for example, I would expect the performance gap to be quite evident.
i think this is a fallacy. none of the reasons i gave above were
catering for dynamic extensibility. it's cost is typically small,
hidden amongst other stuff. the comment about megawidgets is likewise
unfounded.
> It is easy to get seduced into using a particular system, only to
> find out after six months of development that it will not scale up
> to production quality. OTcl is going to require a lot more work
> before David can start to claim that "otcl is a better object system."
the most serious concern you raise for me is that otcl won't
scale. ironically though, it scales more gracefully than itcl. otcl
memory and dispatch may grow linearly with the number of classes (and
hiding the worst-case linear dispatch is the most compelling reason i
see for adding method lookup caching in the future). itcl, on the
other hand, chews through memory at a great rate, with the multiple
interpreter problem swallowing around 50k per class. that's 10mb for a
couple of hunderd classes. (is otcl 100 times more memory efficient? :)
on the whole, i find myself back where i started: the cost of the otcl
approach is reasonable and is unlikely to be bothering people's
apps. there's more to life than method dispatch (i'd worry about
functionality rather than performance) and otcl's lightweight
implementation is a big win, especially for scaling. thanks for the
benchmarks though,
cheers,
djw
Sani_R_Nassif
: Several people on this thread has asked why on earth you would want to
: change a class after it is created. During program development, it
: would certainly be nice to fix bugs or improve behavior of the system
: by changing the definition of a method (and less often adding methods
: or attributes.) Of course I can edit my itcl file and re source it
: but then I have to recreate the state of the program I am debugging.
It is important to recall that the bulk of improvement in development effort
is achieved by going to an interpreted language, since this frees the
developer from the compile/link cycle otherwise necessary. So it is not
clear to me that changing a class definition or method dynamically is
that big a productivity boost.
--
----------------------------------------------------------------------
Sani R. Nassif _ ________
(sani....@att.com) \\/...... /|
(75022...@compuserve.com) \\..... / / Pen Power!
AT&T Bell Laboratories /.\\... / /
1247 S. Cedar Crest Blvd. /...\.. / /
MS 2A218 / / /
Allentown, PA 18103 /Zoomer / /
tel. 610-712-2155 +-------+ /
fax. 610-712-3843 +-------+/ pen.gt.sword
----------------------------------------------------------------------
George A. Howlett
> Now that I am using OTcl, I don't find a strong need for namespaces.
> Methods and instance variables seem to do the trick.
I agree that objects do lessen the opportunity for naming collisions
with Tcl variables and procs. But aren't all objects global? Since
each object and class is represented by a Tcl command, the global
namespace problem has simply been recast.
For example, can your mega-widgets be used to compose larger
mega-widgets. If I like your DefaultButton, can I use it in a
FileBrowser object? Will the user see the DefaultButton class or just
the FileBrowser?
You might be able to manage all of this in a simple, shallow widget
hierarchy (just like we "manage" right now with global arrays). But
if mega-widgets are successful, this won't stay simple or shallow for
long.
Namespaces will allow us to have local objects, packages, better Tcl
libraries, etc. And if Tcl/Tk is going to be successful, we're going
to need all these things.
--gah
Martin Andrews
: > Now that I am using OTcl, I don't find a strong need for namespaces.
: > Methods and instance variables seem to do the trick.
: I agree that objects do lessen the opportunity for naming collisions
: with Tcl variables and procs. But aren't all objects global? Since
: each object and class is represented by a Tcl command, the global
: namespace problem has simply been recast.
I think "put off" or "lessened" is a better way of describing the
situation than "recast". I have fewer Tcl commands and global
variables using OTcl because methods and instance variables are not
global.
: For example, can your mega-widgets be used to compose larger
: mega-widgets. If I like your DefaultButton, can I use it in a
: FileBrowser object? Will the user see the DefaultButton class or just
: the FileBrowser?
Yes. Yes. Yes. The component widgets are still global.
: You might be able to manage all of this in a simple, shallow widget
: hierarchy (just like we "manage" right now with global arrays). But
: if mega-widgets are successful, this won't stay simple or shallow for
: long.
I find it simpler because I can safely ignore the component widgets.
: Namespaces will allow us to have local objects, packages, better Tcl
: libraries, etc. And if Tcl/Tk is going to be successful, we're going
: to need all these things.
I am not saying that namespaces have no place - just that I did not find
them so demanding with OTcl, whereas I did find them demanding before.
I guess it would be nice to hide component objects like you say - though
you could do it with an "auto" command that I use to rename a command
to an objfuscated code name (a hex number) and bind that name to a
variable - say an instance variable. This scheme does not really
remove the command from the global namespace, but it does hide it.
How would your namespace system work? Would there be a flat list
of namespaces - namespace = package name - or could you have a
hierarchy of namespaces. The first only seems an extension of global
data, the second seems more useful but I don't know how it would
be done. Do you have, or know of, any specific proposals for
namespaces? I am not slamming namespaces. I am just trying to
get a clear understanding of what a "namespace" is.
Michael J. McLennan
: In article <DDBEH...@nntpa.cb.att.com> Michael J. McLennan writes:
: > [incr Tcl] is *significantly* faster than OTcl. Method dispatch
: > is typically in the range 2x-4x faster, and object creation
: > can be more than 10x faster. The performance gap gets wider
: > with increasing complexity (increasing levels of inheritance).
: the numbers are interesting, but i don't think your conclusions
: follow. the only real user we've heard from (julian brown) found that
: translating his app to otcl improved performance by a factor of 2-4
: because of its lightweight implementation.
It has nothing to do with "lightweight implementation". His testimonal
compares the *old* [incr Tcl] (version itcl-1.5) to otcl. Since you
were at the recent Tcl/Tk Workshop and you heard my talk, you know that
[incr Tcl] has changed dramatically. I have spent the past nine months
developing a general namespace package for Tcl/Tk, and I used this to
rewrite [incr Tcl] from the ground up. All of this work and attention
to performance has paid off. The new version is considerably faster
than itcl-1.5, and 2x-4x faster than otcl, as shown by my benchmarks.
: to emphasize that you
: should take benchmarks with a grain of salt, consider code where class
: creation is stressed: you'll fine otcl faster by a factor of 10.
This is no reason to take benchmarks with a grain of salt. I haven't
measured this myself, but it merely says this: otcl is better at
defining classes. Since defining classes requires at most a few
hundred milliseconds of startup time, this advantage is insignificant.
: > Since very few real-life applications have methods with null bodies,
: > I benchmarked some non-trivial examples. I didn't try to cook up any
: > special examples.
: methods with empty bodies aren't meant to be realistic, they're meant
: to stress dispatch. your examples have simple methods and are
: essentially reporting on dispatch, though it sounds like you didn't
: intend for this.
My examples show method dispatch and instance variable access in a
realistic environment. The distinction is important: in an idealized
environment (i.e., null method bodies), it appears that [incr Tcl] is
only 1.3x the speed of otcl. But when one method calls another method,
which calls other methods, and so on, the accumulation of dispatch
delays builds to a performance difference of 2x-4x or more. This is
clearly significant.
Also, with null method bodies you completely ignore instance variable
access. Recall that in otcl, you must use the "instvar" method to
access variables. In the benchmark, I showed the example of a
"Counter" class with a "++" method:
Counter instproc ++ {{by 1}} {
$self instvar num
incr num $by
}
Compare this to the corresponding method in [incr Tcl], where variable
access is transparent:
method ++ {{by 1}} {
incr num $by
}
The otcl version requires the extra "$self instvar num" command. This
not only adds noise words and more code to keep up-to-date; more
importantly, it adds more code to *execute*. This is part of the
reason why otcl has fundamentally poorer performance.
: that still leaves itcl method dispatch faster for now. i think there
: are several reasons for this:
: -otcl keeps at arms length from the interpreter (redispatching via
: self) for better implementation modularity/portability
You are quite right about this. [incr Tcl] embraces the interpreter,
to squeeze out better performance. It requires a much greater effort
on my part to get everything right and keep everything up to date, but
I think that the performance gains are worth it.
: -otcl is doing more for you (try renaming an itcl object or class and
: see if the system keeps track of it)
Again, this only applies to the old (itcl-1.5) version. In the next
release, you can rename objects just by renaming the access command.
And you can have objects inside of namespaces, or classes inside of
namespaces. So otcl is not really "doing more".
: -otcl isn't tuned (its compact, without much caching in the dispatch
: until we have a better feel for what should be optimized and what
: should be left alone)
True.
: -itcl is trading worst-case quadratic memory usage for dispatch speed
: (tables of all possible dispatches are precomputed)
False. Again, you are talking about the old version. Again, you should
know since you heard my talk at the workshop, that the new version
requires substantially less memory. There is nothing "quadratic" in
the new version. In fact, some preliminary benchmarks showed that memory
usage was almost identical between otcl and itcl-2.0 for the examples
that I posted.
: the most serious concern you raise for me is that otcl won't
: scale. ironically though, it scales more gracefully than itcl. otcl
: memory and dispatch may grow linearly with the number of classes (and
: hiding the worst-case linear dispatch is the most compelling reason i
: see for adding method lookup caching in the future). itcl, on the
: other hand, chews through memory at a great rate, with the multiple
: interpreter problem swallowing around 50k per class. that's 10mb for a
: couple of hunderd classes. (is otcl 100 times more memory efficient? :)
Again, you are talking about the old version, and merely explaining
to people why it was important that I rewrite it. The new version
uses a namespace to represent each class, instead creating a whole
separate interpreter. This gives better performance and dramatically
reduces the memory usage.
: on the whole, i find myself back where i started: the cost of the otcl
: approach is reasonable and is unlikely to be bothering people's
: apps. there's more to life than method dispatch (i'd worry about
: functionality rather than performance) and otcl's lightweight
: implementation is a big win, especially for scaling.
Excuse me? Let's recap. With these benchmarks, I have been able to
prove that [incr Tcl]...
- has better performance (at least 2x-4x the speed of otcl)
- scales better with increasing class complexity
- has the same memory requirements as otcl
- has more functionality (even Julian Brown said it is "more complete")
There is nothing "lightweight" about a 2x-4x loss in performance. You
may not care how this affects other people's applications, but I do.
That is why I have put so much effort into itcl-2.0.
Chris King
|> Excuse me? Let's recap. With these benchmarks, I have been able to
|> prove that [incr Tcl]...
|>
|> - has better performance (at least 2x-4x the speed of otcl)
|> - scales better with increasing class complexity
|> - has the same memory requirements as otcl
|> - has more functionality (even Julian Brown said it is "more complete")
|>
This all sounds way hip. So the big question is... When will is be ready for
mass consumption.
Chris King
ki...@pixar.com
Michael J. McLennan
: This all sounds way hip. So the big question is... When will is be ready for
: mass consumption.
I responded to a post entitled "When will incr tcl 2.0 be available?" in
this same newsgroup. See this for details. The short answer is this:
I expect to release to a small group of beta testers on September 5,
and if all goes well, itcl-2.0 should be on ftp.aud.alcatel.com by the
end of September.