Itk - the [incr Tk] extension

While writing my one-line summary, I realized there were lots of "nearby" cases I didn't try. Public vs protected vs private being the most obvious. The two levels of inheritance are definitely required. Note that [$a cget -legs] works as expected.

package require -exact Itcl 4.0.3
package require -exact itk 4.0.1

itcl::class Animal {
    inherit itk::Widget

    constructor { args } {}
    public variable legs 4
}

itcl::body Animal::constructor { args } {
    itk_initialize {*}$args
}

itcl::class Cow {
    inherit ::Animal

    constructor { args } {}
}

itcl::body Cow::constructor { args } {
    itk_initialize {*}$args
}

set a [::Animal .a]
puts [$a cget -legs]

set c [::Cow .c]
puts [$c cget -legs]

Thanks for the report.

I won't be on a system where I can easily work on this until
Wednesday, I think, maybe Thursday.

Unless this is really an Itcl problem, and a demo can be
crafted that doesn't demand Itk.  I could work on that
with the systems I have now.

At that point we'll have to see whether a fix is within reach
without putting too much delay on getting the existing set
of fixes out in a release.

The problem here narrows down to this bit of code:

http://core.tcl.tk/itk/info/ca8192d4c6?ln=587-598

Itcl_GetInstanceVar() is passed the name "legs"
and in the first call can resolve that and fetch
the value "4", but in the second cannot so
Itcl_GetInstanceVar returns NULL and the Itk_AddOptionPart
transforms that to the empty string.

In contrast, Itk 3 passes in a full name "::Animal::legs"
which resolves in both cases and always gets the value "4"
so things work.

This suggests a simple fix of passing the string of
ivPtr->fullNamePtr instead.  However, instead of that
resulting in getting a consistent "4" in both cases,
it results in getting a consistent NULL in both cases.  (!)

Still have more drilling to see what's changed so much
in the operations of Itcl_GetInstanceVar().

Fix committed for Itk 4.0.1