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