Arnulf Wiedemann wrote:
>  Do I understand correctly, that is the case when a class method is called 
>  without the "my" in front? In that case there is a problem, if the same 
>  method exists in global namespace, as the object unknown method is called 
>  after looking up in global namespace.

Umm, I'm not sure what the problem is. Methods exist in objects and
classes, not namespaces. That unknown handler is the handler for methods
that are unknown, i.e. it will be called when you do:

   theobject foobarbooftangftangbiscuitbarrel

(Sorry, been listening to Monty Python recordings...)

If you call a command in a namespace, it is first resolved according to
the namespace's resolver policy (including its path and a look in the
global namespace) and only if that search turns up a blank is the
unknown handler for the namespace called (which might or might not be
the same as the global namespace's unknown handler). But that handler is
inherently disjoint from the namespace unknown handler; they've nothing
in common unless you set that to be otherwise. Note that the resolution
to the unknown handler does not go through the mechanisms you set up at
the scripted level; it's an inherent characteristic of the code that
constructs call chains.

FWIW, if a command isn't in a namespace, the namespace's command
resolver gets first bite at the cherry, even before looking in the
global namespace, and I *think* it can inhibit the global lookup. I
could be wrong there; the resolver API is only poorly documented at
best, a consequence of (or maybe reason for) never being made public. If
you are doing things to avoid 'my', you're in the space of commands and
not method names.

I don't know if this resolves your concerns. :-)

(I suppose that the code that sparked this discussion doesn't need an
unknown handler for instance objects; the code to extract the list of
methods could also install forwardings during subclass creation, which
would be faster overall. Designing a good base-class system for widgets
is not the easiest thing ever; there are some tricky nuances.)

Donal.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core