| Store | Cart

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

From: Neil Madden <n...@cs.nott.ac.uk>
Fri, 1 Jul 2005 02:28:00 +0100
On 30 Jun 2005, at 21:33, Donald G Porter wrote:
>>> 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.>>>> Well, you've made it clear we come at this with very different use> cases in mind.  Not too surprising I guess, given the large number> of uses and abuses that [unknown] has had a part in.>> You want to rewrite commands on the fly.  I see [unknown] and> immediately jump to "auto-loader" and want to make the auto-loader> machinery simpler and more reliable.

That *is* one of the use cases I have in mind. We just differ as to  
which namespace should be responsible for loading packages -- calling  
or called. I think if a namespace is calling a command directly then  
it should be responsible for making sure that command exists. That  
seems like good style, and is what the current [namespace unknown]  
proposal would support. I strongly believe that it is the right  
division of responsibility, especially given that you can now  
effectively delegate that responsibility using ensembles. It is  
trivial to get the behaviour you desire from the current proposal  
(target namespace unknown handler gets called):

proc in {ns _do_ args} {
    uplevel 1 [list namespace eval $ns $args]
}

namespace eval ::foo {
     in ::bar do someCmd args...
}

If ::bar::someCmd doesn't exist, then ::bar's handler gets called. (I  
actually think ensembles should work like this). The reverse is much  
harder to achieve.

>> I haven't thought enough about it, but your examples feel to me more> like use cases for the enhanced execution traces I believe Jeff Hobbs> has hinted about proposing.  These would be execution traces> that could have command rewrite capability, which they lack now.

I can't comment on this, because I don't know this proposal. Any  
details?

>> At the very least, those execution trace enhancements would need to> interact with the [namespace unknown] dispatch, so perhaps they need> to be considered together?>> Sorry about erecting obstacles; I really thought you were proposing> something different.

 From Donal:
> Given these differences (and the fact that, like Don, I expected> [namespace unknown] to do something different) I suggest that we do> *not* vote on TIP 181 until we've got that other (alternate?) proposal> more fleshed out. Collecting more use-cases for the different ways  > that> we might wish to use per-namespace unknown command handlers would be> valuable though.

The TIP and reference implementation have been available for over a  
year now. I have patiently waited, responded to comments, updated the  
TIP several times, created 4 separate reference implementations, and  
spent a fair number of hours testing and documenting the change. I  
have even had to update the TIP as a newer proposal ([namespace  
path]) was suggested, voted on, and included in the core in that  
time. Now, the TIP is to be delayed again in case it interacts with  
some functionality that Jeff has "... hinted about proposing"? I  
realise the TCT has a lot of work to do, and I certainly appreciate  
the efforts. But can you give me any idea of how much longer this  
will take?

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

Recent Messages in this Thread
Donald G Porter Jun 30, 2005 08:33 pm
Donal K. Fellows Jun 30, 2005 09:49 pm
Neil Madden Jul 01, 2005 01:28 am
d...@nist.gov Jul 01, 2005 04:08 am
Messages in this thread