[TCLCORE] Re: TIP#181: Add a [namespace unknown] Command

On 30 Jun 2005, at 18:02, d...@users.s wrote:
> I was looking at modifying the> implementation of TIP 181 to> use [::tcl::DefaultUnknown] as> the default [namespace unknown]> handler, when I noticed the> implementation did not work as> I expected it to.>> Then I read the TIP again, and it> proposes something different than> I would expect.>> The relevant example is:>>   namespace eval ::foo {>       ::bar::soom>   }>> I think I want the [namespace unknown]> handler of ::bar to be the one that> goes looking for [::bar::soom], but> what's proposed and implemented is to> have the [namespace unknown] handler> of ::foo do the search instead.

This assumes that there is a ::bar namespace, of course. As we're  
dealing with the situation that a command is unknown, then it is  
perfectly possible that the namespace doesn't exist, and thus has no  
handler. We could fall back on the default (global) handler at that  
point. Personally, I think the currently TIP'ed behaviour is more  
appropriate. If some code I write in namespace ::foo calls some  
command which doesn't exist, it is up to me to figure out what to do  
about that -- e.g., it may be a bug in my code, in which case I might  
want *my* unknown handler to report that. One reason I want the  
current TIP is so that I can do auto-{expand} on a per namespace  
(package) basis, such that I can do:

set old [namespace unknown]
namespace unknown expand
proc expand {cmd args} {
     variable old
     if {[llength $cmd] > 1} {
         uplevel 1 $cmd $args
     } else {
         uplevel 1 $old [linsert $args 0 $cmd]
     }
}
set cmd [list ::foo::sometype: $data]
$cmd method args...

If this results in a call to the unknown handler for the ::foo  
namespace then I have no guarantee that auto-{expand} will actually  
happen. The code becomes dependent on the behaviour of the unknown  
command handler in a namespace I don't "own". That seems like a bad  
idea to me.

Another use for the currently proposed mechanism would be for feature  
detection: I can attempt to use some functionality in some namespace,  
and fall-back if it doesn't exist:

namespace unknown fallback
proc fallback {cmd args} {
     # Figure out a replacement for $cmd
}
foo::bar args...

That way, if foo has a bar command, then everything is good;  
otherwise, my fallback handler can dynamically define a replacement.  
(You could use package versions for this, but there are cases where  
features are added without a version number change, e.g. bleeding- 
edge Tcl 8.5 gets new features all the time, but the version number  
stays the same). Again, this use would not work if the target  
namespace's unknown handler gets called.

Additionally, [namespace ensemble] already handles the other  
situation: calling [::bar soom] will cause the -unknown handler of  
the ensemble to be called in the target namespace. This seems like an  
appropriate division of responsibility.

>> This means each handler can't really be> specialized in a useful way, since they> all have to be able to search for commands> in any namespace, rather than be tasked> with a limited search for commands relevant> to their own namespace only.

I don't really see a problem here. Mostly, I would expect good style  
to move towards calling commands in other namespaces through  
ensembles, in which case this is handled by the -unknown handler of  
the ensemble. So, I would expect in practice most calls to the  
[namespace unknown] mechanism to be for local commands. If not, then  
I still don't think it is a big problem: you presumably know which  
namespaces/packages your own code calls out to, so it shouldn't be  
too difficult to write a specialised handler to deal with those  
cases. The reverse, however, is not true: any number of bits of code  
could call your code and request any command name they like. It would  
be difficult to know in general what the behaviour is expected by  
each different calling namespace, so it is better for them to figure  
out what to do if they call something which doesn't exist.

> Anyhow, I'm surprised by the difference> between the proposal and my expectations.> I suspect others may have misread this one> as well.  At least worth talking about> again.

Sure. Hope I've managed to answer your concerns.

-- Neil


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core