Am Dienstag, 27. Mai 2008 16:36:35 schrieb Donal K. Fellows:
>  Will Duquette wrote:
>  > In other e-mail on this list, I discussed this with Arnulf; he's got a
>  > working implementation for Itcl-ng.  Snit variables are (so far as I
>  > can see) equivalent to Itcl-ng "protected" variables.  Instance
>  > variables appear with unqualified names unless there's a conflict, in
>  > which case they are qualified by the namespace of the class in which
>  > they are defined.  It seems reasonable to me that Snit and Itcl should
>  > work the same way in this regard.
> 
>  OK, a variable resolver. (That's a corner of Tcl I'd hoped to never have
>  to understand; looks like I won't get my wish...)
> 
>  > They certainly should be.  "Submethods", as you call them, are no
>  > different than regular methods except in how they are called.  As an
>  > example from Tk, the text widget has a "tag add" method.  It could
>  > have been implemented as "tag_add" instead, but making "tag" a
>  > subcommand with its own subcommands makes the set of text widget
>  > methods easier to document, to understand, and to use.  Snit
>  > submethods are the same way.  But this is really syntactic sugar, as
>  > one could express the same functionality with a single set of non-
>  > hierarchical subcommands.  It's just really good, tasty, sugar. :-)
> 
>  OK. The tricky case it is then. That'll require a future TIP, as it is
>  beyond the level of features that can be controlled right now. (Some
>  tweaks are going to be needed to the dispatch engine, and there are
>  going to be other tricky cases too. Not this week or the next though;
>  I've got a big conference coming up...)
> 
>  >>    method unknown {args} {
>  >> 	if {[string match .* [lindex $args 0]]} {
>  >> 	    return [uplevel 1 [list [self] create {*}$args]]
>  >> 	}
>  >> 	next {*}$args
>  >>    }
>  >
>  > That's indeed cool, though I'd need to roll in support for Snit's
>  > "delegate typemethod *" functionality.
> 
>  Ah, that method is set on the class object (or rather on the class of
>  widget class objects, which is one of the reasons why metaclasses are
>  good)|and not on the instance object. Instances have their own unknown
>  handler which does something rather like 'delegate typemethod *' except
>  that it effectively caches the method for future use:
> 
>       method unknown {method args} {
>  	my variable w
>  	if {$method in [my Class getMethods]} {
>  	    oo::objdefine [self] forward $method $w $method
>  	    return [$w $method {*}$args]
>  	}
>  	return -code error "unknown subcommand \"$method\"..."
>       }
> 
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.

Arnulf
>  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



-------------------------------------------------------------------------
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