tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP 287 [chan available] reference implementation

[Michael A. C. <mi...@cl...>]

On 10/30/06, Andreas Kupries <and...@ac...> wrote:
> Ok, I also found an older RFE by Colin McCormack
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1399062&group_id=10894&
> atid=360894
>         gets with limited line-length
>
> I think this should be discussed in the TIP

I haven't downloaded the patch attached to Colin's RFE yet to see
(will do so tonight), but with the various ways one can call [gets] (0
to 3 arguments currently) the semantics seem like they could get a bit
messy if -maxchars were supported in all flavors.

Also I think you'd want to be able to distinguish between the case
where you got -maxchars because that is exactly what was there to be
read and when you got -maxchars because you hit the maximum.  I
suppose you could distinguish the case by requesting -maxchars [expr
{$limit + 1}] and then testing [string length $line] to see if it were
just $limit or ($limit + 1) ...

Anyway, I think [chan available] is a good fit with the new [chan]
ensembles in 8.5 and approving the TIP shouldn't preclude a separate
TIP for changing [gets] in my opinion.

Michael

[TCLCORE] Ttk now in CVS

[Jeff H. <je...@ac...>]

After review of the sandbox by various parties, we have made a first 
commit of themed Tk (Ttk, aka tile) to 8.5.  This is a branch of tile 
from v0.7.8, with some variations.  There is no Ttk or tile package in 
this, it is simply Tk 8.5a6 (which you can thankfully now request by 
exact patchlevel).

It currently builds and runs across the platforms.  There is an issue 
with 'make test' in the safe.test suite in that it fails to run due to 
some non-safe code usage in the ttk library initialization (though it 
runs fine when testing by hand ... ugh, safe interp debugging is a pain).

We will be refining and improving the actual themed parts, along with 
documentation, demos and refinement of what exactly is public for 8.5. 
I welcome everyone to start poking and prodding now though.

Enjoy,

Jeff

Re: [TCLCORE] CFV: TIP #174: "Math Operators as Commands"

[miguel <ms...@us...>]

My vote:

TIP #174: YES

Miguel

Re: [TCLCORE] TIP 287 [chan available] reference implementation

[Andreas K. <and...@ac...>]

> Using the attached scripts (yyy = sender incomplete line, zzz =
> sender complete
> line, xxx = receiver), I find that after each push of an incomplete
> line to the
> socket the receiver calls the event handler only twice and then
> stops. Until the
> next chunk is received. Without the special case it would expect it to execute
> the handler rapidly without stopping, until the line has been completed ...
>
> Interesting. Now I am wondering how this is implemented.

Aha. tclIO.c, Tcl_GetsObj, line 3854 (8.4 head, end of the function).
CHANNEL_NEED_MORE_DATA flag ...

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [TCLCORE] TIP 287 [chan available] reference implementation

[Andreas K. <and...@ac...>]

> I've updated TIP #287 (which proposes a [chan available]) command with
> a pointer to the reference implementation/patch at SourceForge (RFE
> 1586860).  See: http://www.tcl.tk/cgi-bin/tct/tip/287.html.
> The patch also includes updated man pages and test cases.
>
> Naturally feedback is appreciated.  I think this should be a
> relatively uncontroversial TIP as it fits in nicely with the new
> [chan] command in 8.5 (and will help authors of network daemons to
> avoid a certain class of DoS attacks).

Michael,

your are quoting from fileevent.n:

	A channel is also considered to be readable if there is unread
	data in an input buffer, except in the special case where the
	most recent attempt to read from the channel was a gets call
	that could not find a complete line in the input buffer.

I am not aware of this special case, and think that the manpage might be
wrong.

... Writing a test script ... Ok I seem to be wrong.

Using the attached scripts (yyy = sender incomplete line, zzz = sender complete
line, xxx = receiver), I find that after each push of an incomplete line to the
socket the receiver calls the event handler only twice and then stops. Until the
next chunk is received. Without the special case it would expect it to execute
the handler rapidly without stopping, until the line has been completed ...

Interesting. Now I am wondering how this is implemented.


Ok, I also found an older RFE by Colin McCormack


http://sourceforge.net/tracker/index.php?func=detail&aid=1399062&group_id=10894&
atid=360894
	gets with limited line-length

I think this should be discussed in the TIP

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [TCLCORE] TIP#290 Published

[Eckhard L. <ec...@gm...>]

Tom Krehbiel schrieb:
> Is the reference implementation compatible with threading?

The reference implementation can be found here: 
http://sourceforge.net/support/tracker.php?aid=1587317.

I did not care in particular about thread safety, but the handler is 
stored and run on a "per Interp" basis.
This means that it must be registered separately for each thread - and 
when an error comes up there, the handler is run in the Interp of this 
thread (the current thread can be retrieved with [thread::id] in the 
handler script).

I did some testing with multi threads, and it works (more tests will be 
added later to the testsuite).


Eckhard

Re: [TCLCORE] CFV: TIP #174: "Math Operators as Commands"

[Jim I. <ji...@ap...>]

TIP #174: YES

Jim

On Oct 30, 2006, at 11:35 AM, Kevin Kenny wrote:

> As I warned last week, I'm calling the vote on
>
>      TIP #174: "Math Operators as Commands"
>
> Please send votes to me by [clock format 1162832400].
>
> My vote:
>
> TIP #174: YES
> --
> 73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
> ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
>                              Schenectady, New York 12301-0008 USA
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Update Status TIP #280: Add Full Stack Trace CapabilityWithLocation Introspection

[Andreas K. <and...@ac...>]

The TIP has been extended to cover 8.5 features, like {expand}, the dict
for/with, etc.
We now also have an implementation/patch for 8.5 as well, against the hea=
d.
Please test.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122


> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Andreas
> Kupries
> Sent: Friday, October 20, 2006 9:05 AM
> To: tcl...@li...
> Subject: Re: [TCLCORE] TIP #280: Add Full Stack Trace
> CapabilityWithLocation Introspection
>
>
>
> > 2006-10-19 kl. 21.43 skrev Andreas Kupries:
> > >>> This is directly taken from the 'interp->scriptFile' structure
> > >>> element.
> > >>> In other words: Whatever would be delivered by [info source] for =
the
> > >>> file, if
> > >>> called at the same effective location.
> > >>
> > >> In other words, something not quite as useful as it could have bee=
n.
> > >> Pity, but I suppose there might be a cost for normalising file nam=
es
> > >> involved.
> > >
> > > Its not as bad, Don Porter sent the name of the function to call. S=
o
> > > yes, there
> > > will be a cost, but only at the time the [info frame] is called.
> >
> > That's not good enough; you need to do it when the file is opened, or
> > else the [pwd] might have changed by the time you request the
> > information. Consider the following interactive sequence of commands:
> >
> >    % cd sourcedir
> >    % source mystuff.tcl
> >    % cd ../testdir
> >    % source mystuff.tcl
> >    % runTest
> >
> > Now which mystuff.tcl did a particular proc come from?
> >
> > Lars Hellstr=F6m=3D
>
>
> Don Porter pointed this out as well, including that 'source' itself als=
o does
> normalization, and the result is cached, thus there is no real
> additional effort
> involved if I do it as well. The newest patches on SourceForge (base4+)
> implement this already, i.e. normalization when the frame is constructe=
d in
> 'source', not by 'info frame'.
>
> --
> 	Andreas Kupries <and...@Ac...>
> 	Developer @ http://www.ActiveState.com
> 	Tel: +1 778-786-1122
>
>
>
> -----------------------------------------------------------------------=
--
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job =
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP #174: "Math Operators as Commands"

[Joe E. <jen...@fl...>]

Kevin Kenny wrote:
>
> As I warned last week, I'm calling the vote on
>
>      TIP #174: "Math Operators as Commands"

TIP#174: YES

(A very enthusiastic YES...)


--Joe English

  jen...@fl...

Re: [TCLCORE] TIP#290 Published

[Tom K. <tom...@fr...>]

Is the reference implementation compatible with threading?
Tom K.

> Hi everyone!
> 
> This is just a quick note to say that TIP#290 "Registration of Custom
> Error Handler Scripts" has been published at:
>     http://tip.tcl.tk/290.html
> 
> I'd send out the usual publication email, but the machine (and the whole
> network segment) that I use for that seems to be down. :-\
> 
> Donal.
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] TIP 272 (WAS Re: CFV: TIPs 272, 274)

[Joe E. <jen...@fl...>]

Kevin Kenny wrote:
>
> TIP #272: PRESENT
>     Does this TIP have a use case other than benchmarksmanship?

I can think of plenty of times when I've needed to
iterate over a list from back-to-front; in such
situations "foreach e [lreverse $l] {...}" is a
much more pleasant solution than the equivalent
"for {...} {...} {...} {...}" loop.

[string reverse] has fewer apparent use cases, but
there are a couple --

    map {string reverse} [lsort [map {string reverse} $filenames]]

is a quick-and-dirty way to collate a list of filenames
by extension for instance.


--Joe English

  jen...@fl...

Re: [TCLCORE] CFV: TIPs 272, 274

[Jim I. <ji...@ap...>]

On Oct 30, 2006, at 9:16 AM, Donald G Porter wrote:

>
> As promised, here's the call for votes for TIPs 272 and 274.
>
> Please send votes to TCLCORE and/or back to me before the polls  
> close at
> [clock format 1162573200].
>
> TIP #272: String and List Reversal Operations
>
> TIP #274: Right-Associativity for the Exponentiation Operator
>
> My votes:
>


272:	YES - I've wanted to do the list version of this sometimes (never  
the string one, but it doesn't hurt).
274:	YES

Jim

[TCLCORE] CFV: TIP #174: "Math Operators as Commands"

[<ke...@cr...>]

As I warned last week, I'm calling the vote on

     TIP #174: "Math Operators as Commands"

Please send votes to me by [clock format 1162832400].

My vote:

TIP #174: YES
--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [TCLCORE] CFV: TIPs 272, 274

[<ke...@cr...>]

TIP #272: PRESENT
    Does this TIP have a use case other than benchmarksmanship?

TIP #274: YES
    Correcting a bug in the original specification.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [TCLCORE] CFV: TIPs 272, 274

[Joe E. <jen...@fl...>]

Donald G Porter wrote:
>
> As promised, here's the call for votes for TIPs 272 and 274.
>
> Please send votes to TCLCORE and/or back to me before the polls close at
> [clock format 1162573200].
>
> TIP #272: String and List Reversal Operations
> TIP #274: Right-Associativity for the Exponentiation Operator

TIP#272: YES
TIP#274: YES

--Joe English

  jen...@fl...

[TCLCORE] TIP #289: Revision of [lrepeat] Argument Order

[Donald G P. <dg...@ni...>]

TIP 289 proposes a change from syntax

   lrepeat $number $element $element ...

to

   lrepeat $element $element ... $number

The main feature that appears to get lost in this change is the ability 
to redirect aliases or subcommands of ensembles to [lrepeat] calls with 
the number of repetitions already filled in.

Anyone know of examples of making use of this capability?

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] CFV: TIPs 272, 274

[Andreas K. <and...@ac...>]

> TIP #272: String and List Reversal Operations
> TIP #274: Right-Associativity for the Exponentiation Operator

My votes:

TIP#272:	YES
TIP#274:	YES

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122

Re: [TCLCORE] CFV: TIPs 272, 274

[miguel <ms...@us...>]

Donald G Porter wrote:
> As promised, here's the call for votes for TIPs 272 and 274.
> 
> Please send votes to TCLCORE and/or back to me before the polls close at 
> [clock format 1162573200].
> 
> TIP #272: String and List Reversal Operations
> 
> TIP #274: Right-Associativity for the Exponentiation Operator
> 
My votes:

272:	YES
274:	YES

Miguel

[TCLCORE] CFV: TIPs 272, 274

[Donald G P. <dg...@ni...>]

As promised, here's the call for votes for TIPs 272 and 274.

Please send votes to TCLCORE and/or back to me before the polls close at 
[clock format 1162573200].

TIP #272: String and List Reversal Operations

TIP #274: Right-Associativity for the Exponentiation Operator

My votes:

272:	YES
274:	YES

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] Odd 257 behavior

[Donal K. F. <don...@ma...>]

Gustaf Neumann wrote:
> Will Duquette schrieb:
>> TIP 257 is much faster than Snit 2.x in other areas (e.g.,
>> object creation, where it's faster by an order of magnitude).
> 
> i don't have the impression that object creation is blazing fast with 
> tip#257 (see as well the message above).

Benchmark duelling? Ick. (The #257 code doesn't bother trying to put off
namespace creation until the first method call, on the grounds that
practical code will almost always have some per-object state to be kept
in the object's namespace and so putting off creation won't win much at
all. So currently I leave the code simple-to-write - and hence easy to
understand - instead of going for chiselling a tiny bit for benchmarks'
sake.)

Donal.

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Donal K. F. <don...@ma...>]

ju...@pr... wrote:
> What I've seen referred to as the 'invocant'.
> Is this 'object invocation context' assumed to involve the context of just one object?
> 
> Whilst I'm not yet sure how these method/proc thingies will operate - can you please consider if it makes sense to accept multiple invocants for oo systems that may like to use this feature?
> 
> ie some oo extension may want to invoke a method in the context of more than one object at once.
> see http://en.wikipedia.org/wiki/Multimethods

Umm, so far we've not been truly doing anything in Tcl involving types
in the sense that that article describes (as "everything is a string"
you know), so for now I'm going to keep on doing nothing. :-)

> This isn't really a specific request I guess.. just a nudge towards generalization of the invocant/dispatch stuff if it happens to make sense.
> 
> I've been toying with the idea of multiple dispatch for my own oo system - but never came up with anything concrete.

You could probably do it with a custom method type (something I do
support) I suppose. Anything else would require a different (and much
more expensive) way of managing the binding of "method name" to
implementation.

Donal.

[TCLCORE] TIP#290 Published

[Donal K. F. <don...@ma...>]

Hi everyone!

This is just a quick note to say that TIP#290 "Registration of Custom
Error Handler Scripts" has been published at:
    http://tip.tcl.tk/290.html

I'd send out the usual publication email, but the machine (and the whole
network segment) that I use for that seems to be down. :-\

Donal.

[TCLCORE] TIP 287 [chan available] reference implementation

[Michael A. C. <mi...@cl...>]

I've updated TIP #287 (which proposes a [chan available]) command with
a pointer to the reference implementation/patch at SourceForge (RFE
1586860).  See: http://www.tcl.tk/cgi-bin/tct/tip/287.html.
The patch also includes updated man pages and test cases.

Naturally feedback is appreciated.  I think this should be a
relatively uncontroversial TIP as it fits in nicely with the new
[chan] command in 8.5 (and will help authors of network daemons to
avoid a certain class of DoS attacks).

Michael

Re: [TCLCORE] oo-oh ... not ready for 8.5

[<Lar...@re...>]

2006-10-27 kl. 16.47 skrev miguel sofer:
> Lars Hellstr=F6m wrote:
>> 2006-10-27 kl. 00.30 skrev Donal K. Fellows:
>>> I (reluctantly) agree to not
>>> push for any OO system in 8.5 on the proviso that we stick to that
>>> short
>>> cycle for 8.6 (I hate committing to 8.6, but we need a version out=20=

>>> with
>>> an OO system so that it can get extensive in-field testing before =
9.0
>>> when it would be nice to see how much of Tk can be founded on=20
>>> objects.)
>>
>> It occurs to me that this "8.5 will be the last 8.x, then it's 9.0 =
all
>> the way" additude may be the culprit on which most of the blame for=20=

>> the
>> 4 years (and counting?) release cycle of 8.5 should be placed. If
>> something is going to be the last in its kind -- the zenit of
>> technological ingenuity -- then it is hard to let go of it, because
>> there is always some more polishing to do and features to stick in.
>> OTOH, as long as there will be a new model next year, then some of =
the
>> goodies can get to wait for that.
>
> The problem is partially that some of the goodies *have* to wait for
> 9.0: we cannot break compat in a point release, and compat makes some
> things impossible.

Sure, but I was speaking rather about the evolution of the 8.x line.=20
While some improvements certainly require a major version update, there=20=

always seems to be a lot more which can be put in place already in the=20=

next 8.x.

>> There have been plans for what should be in various releases along =
the
>> way (I vaguely recall something about 8.5 should be all about=20
>> improving
>> Tk), but it's my impression that the TIPs actually submitted didn't
>> match those expectations; there turned out to be a lot that could be
>> improved in Tcl as well. There probably still is (although 8.5 now
>> meets an anstonishingly large amount of the things that have been on=20=

>> my
>> wish list).
>>
>> At the current rate of ingenuity coming in, I wouldn't be totally
>> surprised if there gets to be an 8.7 as well. In that case, it would
>> probably be a good idea to not wait until 2010 to accept the notion,
>> and instead let it come naturally if/when it comes.
>
> It is also a matter of energy and manpower. We now keep two active
> branches; opening 9.0 while keeping development for the 8.x means =
three
> active branches, with one of them diverging constantly. Development of
> new features becomes very hard, porting between the branches difficult
> and extremely work intensive.

So? Obviously no development would take place on the 8.x branch is=20
noone bothers to do the work. There's a huge difference between not=20
doing anything and being forbidden[*] to do it however, and it is the=20
leaning towards the latter that worries me.

([*] Yes, you could claim that since it's Open Source noone can be=20
forbidden to do development, but with that lofty argumentation one=20
could equally well deduce that there's no need ever to officially go to=20=

Tcl 9 since anyone who wants to break compatibility can do so on their=20=

own. (Come to think of it, some have already done that.))

> So *my* hope is that
>
> (1) we will have a development branch that is free from any compat
> commitments (especially binary, and not even source for extensions=20
> using
> tclInt.h). Which does not mean anybody will break things randomly and=20=

> on
> purpose.
>
> (2) we will keep 8.x on maintenance: bugfixes mainly.
>
> If there appear volunteers (or paid workers, or the $$$ to create
> volunteers) most features maybe can be backported. But backporting
> should not constrain the design of new features.

I suspect there would be quite a large timeframe within which things=20
would be forward-ported rather than backported, i.e., the little=20
improvements (like [chan available]) would primarily be done in 8.x,=20
because that is where people need them.

> Nothing stops us from
> having different teams for 9.x and 8.x, except that we are already too
> small a team for one of them.

As I recall it, it is not the TCT that is required to implement TIPs,=20
but rather the proposers. When the focus has shifted to 9.0, the 8.x=20
development (and releases) should slow down to halt gradually, rather=20
than end with a bang.

> In short, at least for me: 9.0 is not an excuse not to develop new
> features because they can always go in tomorrow. Rather, 8.x is like a
> cage that stops development or makes it difficult; 9.0 is freedom.

My point is that "after 8.5 comes 9.0" has been an excuse for=20
*delaying* 8.5, because if 8.5 shipped without feature X then X would=20
have had to wait for 9.0 (i.e., probably very long) to be available,=20
since it was proclaimed that there wouldn't be an 8.6. If 8.5 had not=20
been planned as the end of the 8.x series, then I suspect it would have=20=

already been final (probably with {expand}, ensembles, and [dict] (thus=20=

making the backport dict for 8.4 extension unnecessary), but without=20
[apply] and bignums) and it would have been 8.6 that was about to go=20
beta about now.

> As an example, you can look at some of the tips that target 9.0.

Another point to note: There aren't very many of them! The last 9.0 TIP=20=

was #192, and we're now at #289. This is to me a clear sign that the=20
incentives for development within the 8.x line are far from exhausted.

> Or consider that we could possibly make the core much more sparing in
> memory and runtime if we could share the string rep of Tcl_Objs,=20
> storing
> also lengths and hashed values in the same struct as the string. Or
> develop continuations, which may imply a change in some public apis.

Sure, all good things, but I wouldn't want to hold my breath until they=20=

arrive. I also wouldn't want to see simple improvements (such as #286)=20=

having to wait until these tricky things have been sorted out.

> Or do automatic expansion of leading words in commands -

Nah, that's such a DWIMerism. {expand} already solves the problem, even=20=

if some may find the syntax unappealing.

> breaking current
> command names with spaces, but allowing true lambdas and efficient use
> of command prefixes. Or ... the sky's the limit.

Yes, but there are still plenty of things that can be constructed=20
within the hangar of 8.x compatibility, and in the 9.x building-site=20
the foundation hasn't even been laid yet. ;-) The promise of a future=20
Paradise is not a reason for putting a stop for improvements to the=20
here and now.

Lars Hellstr=F6m=

Re: [TCLCORE] Pre-CFV - TIP#257,#279

[Twylite <tw...@cr...>]

DKF wrote:
 > Maybe. Or maybe it's delegative OO (see Snit) that's Tcl's true nature?

I like Snit's delegative approach a lot -- it is powerful and easy to 
understand.  What a delegative approach lacks though is polymorphism. 

This means that with delegation it is easy to add behaviour to another 
object/class (using the decorator pattern), but difficult to change 
(adapt) the behaviour of another object/class unless that object 
provides explicit hooks (events, callbacks, etc) to do so.

I think I need an example here to add clarity:

- objB decorates objA, adding a new method "x" and overriding the method 
"calc"; all other methods are delegated.
- If you have a variable A and assign to it either objA or objB, then in 
all cases when you use $A it will appear to be an object of type classA, 
with polymorphic behaviour (in that if A is set to objA then the calc 
method of classA will be used, and if A is set to objB then the calc 
method of classB will be used).

BUT

- objA has a method "increment" that updates some internal value and 
calls "calc".
- objB delegates "increment" to objA
- When "increment" is called on objB, the resulting call to the "calc" 
method is called on objA _not_ on objB.

True polymorphic behaviour can be very useful in a lot of circumstances, 
including extending widgets. 

I think Tcl's true nature (when it comes to OO) hasn't been found yet, 
but it is a blend of delegative, class-based and prototype ;)

My 2c.
Twylite