does anyone care about iwidget bug reports?
Bryan Oakley
I was looking at the incr tcl sourceforge page and virtually nothing has
been touched in years. When I do a search at activestate for iwidget or
itk bugs there are none, so I'm left with the feeling that all iwidget
bugs are left to roam the earth until the end of time.
I recently helped a co-worker with a second iwidget bug today, and it
astounds me that such an obvious bug could survive unreported and
unfixed for nearly four years. "Astounded" because I had assumed that
iwidgets was still in use somewhere, but I'm beginning to think we're
the last project on earth using it.
I'd be happy to submit reports and supply a patch now and again, but I
get the feeling it will not so much fall on deaf ears but rather fall on
no ears at all.
--
Bryan Oakley
Jeff Hobbs
iwidgets has faded in popularity for new development over the last few
years. First BWidgets, then tile and other alternatives have popped up
that replaced it. Nowadays I wouldn't even use itcl due to its overly
inflexible development-by-contract model (I like to resource my files,
which may mean dynamic modification of classes, to speed development).
If you want to provide patches, I would be willing to give you direct
commit access to iwidgets. However, if you are doing new development, I
would recommend alternatives.
--
Jeff Hobbs, The Tcl Guy, http://www.activestate.com/
Ralf Fassel
| Nowadays I wouldn't even use itcl due to its overly inflexible
| development-by-contract model (I like to resource my files, which
| may mean dynamic modification of classes, to speed development).
We have during development
catch {itcl::delete class xyz}
::itcl::class xyz { ... }
The "itcl::delete class" is then commented out before final tests and
commit.
Just my EUR0.01
R'
Tim Wallace
does things the built-in paned window won't do) to ipanedwindow. But
there are a lot of them we don't use. It would be a pretty big job to
port our whole system to another widget package, so we're certainly
hoping they stay around!
--Tim
Jeff Hobbs
> We use them. Biggest change we make is to change the panedwindow (which
> does things the built-in paned window won't do) to ipanedwindow. But
> there are a lot of them we don't use. It would be a pretty big job to
> port our whole system to another widget package, so we're certainly
> hoping they stay around!
They aren't going anywhere, they just aren't being updated to the latest
look and feel. If you were to target OS X Aqua for example, iwidgets
looks quite out of place, whereas we can achieve native look with
tile/ttk and building up from there.
> Ralf Fassel wrote:
>> * Jeff Hobbs <je...@activestate.com>
>> | Nowadays I wouldn't even use itcl due to its overly inflexible
>> | development-by-contract model (I like to resource my files, which
>> | may mean dynamic modification of classes, to speed development).
>>
>> We have during development
>>
>> catch {itcl::delete class xyz}
>> ::itcl::class xyz { ... }
>>
>> The "itcl::delete class" is then commented out before final tests and
>> commit.
That deletes existing objects of that class and derived classes as well.
I don't want to do that, just modify the class. The class
restrictions is the primary thing I dislike about itcl. It is one
feature taken from the C++ heritage that should not have been retained
for a language so dynamic as Tcl.
Ralf Fassel
| The class restrictions is the primary thing I dislike about itcl.
| It is one feature taken from the C++ heritage that should not have
| been retained for a language so dynamic as Tcl.
Well, our 'binary' development language is (guess!) c++, so no
surprise I'm not sooooo annoyed by Itcl :-)
R'
Eckhard Lehmann
Jeff Hobbs wrote:
> That deletes existing objects of that class and derived classes as well.
> I don't want to do that, just modify the class. The class
> restrictions is the primary thing I dislike about itcl. It is one
> feature taken from the C++ heritage that should not have been retained
> for a language so dynamic as Tcl.
Some time ago I proposed an [itcl::class configure] command that makes
it possible to configure class variables/methods and it's objects at
runtime.
(1145864157.2...@v46g2000cwv.googlegroups.com)
Nobody gave any input. It wouldn't be that hard, really... maybe I
should just do it when I have enough time and feel like doing it.
We don't get around the fact that Itcl is a class based OO system
rather than an object based one (as XOTcl) - but in many standard cases
this has advantages... IMO, the "contract" system makes the code better
understandable than having an uncontrolled growth of not classified
objects at runtime.
But - out of the box - you can source the method body implementations
for classes at runtime... isn't this fine in many cases?
Eckhard
MH
Same here.. Itcl seems to work just fine for us..
MH
Arnulf Wiedemann
>
> Jeff Hobbs wrote:
>
>> That deletes existing objects of that class and derived classes as well.
>> I don't want to do that, just modify the class. The class
>> restrictions is the primary thing I dislike about itcl. It is one
>> feature taken from the C++ heritage that should not have been retained
>> for a language so dynamic as Tcl.
>
> Some time ago I proposed an [itcl::class configure] command that makes
> it possible to configure class variables/methods and it's objects at
> runtime.
> (1145864157.2...@v46g2000cwv.googlegroups.com)
>
> Nobody gave any input. It wouldn't be that hard, really... maybe I
> should just do it when I have enough time and feel like doing it.
> We don't get around the fact that Itcl is a class based OO system
> rather than an object based one (as XOTcl) - but in many standard cases
> this has advantages... IMO, the "contract" system makes the code better
> understandable than having an uncontrolled growth of not classified
> objects at runtime.
I agree!!
>
> But - out of the box - you can source the method body implementations
> for classes at runtime... isn't this fine in many cases?
>
>
> Eckhard
Hello Eckard,
I would be very interested, if you would add the configure, because I also
think it would be very useful. I also prefer the style of itcl to xotcl,
maybe because of my C++ background. If you need someone to test the feature
after implementation, please contact me, I am willing to help.
Arnulf
GN
> this has advantages... IMO, the "contract" system makes the code better
> understandable than having an uncontrolled growth of not classified
> objects at runtime.
hmm, after having written a few hundred xotcl programs, i have not
noticed
this behavior. How comes, that you believe that this happens? There are
by design no "not classified" objects in xotcl. Every object has a
class.
> But - out of the box - you can source the method body implementations
> for classes at runtime... isn't this fine in many cases?
What's your argument? dynamic modifications of classes are bad,
sourcing is kind of ok?
Helmut Giese
I think it is _very_ important to not mix IWidgets and ITcl in the
discussion here. While IWidgets might not have a future anymore, ITcl
is IMHO an important part of Tcl.
The reason is simple: ITcl implements the OO model which is most
widely known by programmers coming from other languages:
- They come from C++? Well, they can start using it right away.
- Delphi (Pascal)? It's close enough so that they get up to speed
soon.
- Java? I assume the above is true, too.
IMHO the average programmer is not too OO savvy, and if they do use OO
they are likely to know or master just one model. (Imagine an ordinary
C++ guy: How many OO models is he likely to know? I strongly believe
that for the large majority the way C++ does OO _is OO_ for them -
they wouldn't imagine that other - possibly more powerful - models
even exist. At least for me this was true: I learned different models
when I came here.)
These folks are not like you :) - you know that Tcl offers (at least)
3 different models, and for the task at hand you choose the one which
is most appropriate - or just roll your own on a lazy afternoon.
I am convinced that for the good of Tcl, ITcl needs a high visibilty,
so that when people from other languages come here and want to do OO,
they see something familiar. If then they find out that there are more
ways to do OO - well, all the better. But when venturing into
something new, familiarity is a big boon - and ITcl is the only one of
Tcl's OO models which can offer this.
This being said,
>Some time ago I proposed an [itcl::class configure] command that makes
>it possible to configure class variables/methods and it's objects at
>runtime.
>(1145864157.2...@v46g2000cwv.googlegroups.com)
>
>Nobody gave any input. It wouldn't be that hard, really... maybe I
>should just do it when I have enough time and feel like doing it.
I think, maybe you should :)
Just my 0.02
Helmut Giese
Eckhard Lehmann
GN wrote:
> Eckhard Lehmann schrieb:
>
> > this has advantages... IMO, the "contract" system makes the code better
> > understandable than having an uncontrolled growth of not classified
> > objects at runtime.
>
> hmm, after having written a few hundred xotcl programs, i have not
> noticed
> this behavior. How comes, that you believe that this happens? There are
> by design no "not classified" objects in xotcl. Every object has a
> class.
>From my last glance at the XOtcl tutorial (which was approx 1 year ago)
I believe to have read, that it is possible to create objects without
any class and assign attributes to them.
I find it better to know what type ( class) an object is from when I
need to understand a (big) program. It makes it easier to rely on a
description of it's possible state, e.g: object a is of class A and has
attributes b, c,..., nothing more or less - and this doesn't change
over the program runtime.
>
> > But - out of the box - you can source the method body implementations
> > for classes at runtime... isn't this fine in many cases?
>
> What's your argument? dynamic modifications of classes are bad,
> sourcing is kind of ok?
If dynamic modifications to class *definitions* resp. single object
*definitions* occurs during runtime, that might be bad.. yes that is my
concern. Imagine a big program running over a long time; and the
objects it consists of have different attributes, depending on time and
several conditions... it could be hard to track this down in debugging
sessions, especially if you loose the overview about when and why which
attribute definition changed for which object.
When I talk about the [itcl::class configure] command, the situation is
similar, but not to the same extend: here, the attributes for a class
and _all_ it's objects are changed, so after reconfiguration, the
definition of every object is again the same and you can again rely on
the new definition. Still, this should be used sparingly... I can
imagine one usecase in implementing database persistence layers (object
attributes change with DB table fields).
Sourcing into running application is different, since it is mainly used
for changes to the code during development - to rapidly test new code
without the need to restart the whole application. Here it is good when
the class/object definition can be changed during runtime. But usually
you don't source into a program that is already deployed to your
customers.
Eckhard
Eckhard Lehmann
Arnulf Wiedemann wrote:
> Hello Eckard,
> I would be very interested, if you would add the configure, because I also
> think it would be very useful. I also prefer the style of itcl to xotcl,
> maybe because of my C++ background. If you need someone to test the feature
> after implementation, please contact me, I am willing to help.
Thank you, Arnulf.
I can't give a time schedule when it will be finished (not even when I
will start) - I am quite busy at the moment...
But I'll get back to your offer, when it is time ;-)
Eckhard
Jawn
My project also uses iTcl and iWidgets, so we hope they hang around
a while too.
John
Jawn
My project also uses iTcl and iWidgets, so we hope they hang around
iTcl
is a natural to learn/use.
John