From: Duquette, W. H (318K) <wil...@jp...> - 2012-11-20 19:03:58
|
On 11/20/12 10:36 AM, "Brian Griffin" <bri...@me...> wrote: >On Nov 20, 2012, at 9:59 AM, Duquette, William H (318K) wrote: > >> On 11/19/12 3:48 PM, "Brian Griffin" <bri...@me...> wrote: >>> >>> Data point: we use [unknown] to throw commands to another process via >>>an >>> RPC mechanism. It makes two processes/interps act as one. Kinda cool. >> >> Yes, [unknown] is useful, no question. But we have [unknown] and >> [namespace unknown]. Would a [namespace unknown] handler on :: not do >> what you want? > >If there's any distinction it must be subtle since I don't see the >difference. Therefore, a :: namespace unknown should work just as well. When in doubt, RTFM. I've now done so; and as I read it [unknown] and [namespace unknown] are complementary. Here's how it works: if you execute a command in namespace $ns, and the command can't be found in the usual places ($ns itself, on its namespace path, or in ::) then the unknown handler for $ns is called. By default, the unknown handler for all namespaces is ::unknown. Thus, setting [namespace unknown ::] has no effect at all on calls to unknown commands from other namespaces, whereas (by default) redefining ::unknown affects calls to unknown commands in all namespaces. Or, to put it more plainly, redefining ::unknown lets you specify the default handling for unknown commands in your application, and setting [namespace unknown $ns] lets you customize it for commands called in $ns only. Get rid of ::unknown, and there's no way to handle the default case. Consequently, I'll withdraw the suggestion to remove ::unknown. |