No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] nested objects in nx
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 29 Oct 2010 09:56:23 +0200
Dear victor,
There is a difference/asymmetry between
"namespace path" and "namespace import"
* "namespace import" creates cmd-stubs in the actual namespace
(if issued on "::", in the top-level namespace). The
default rule
for function resolving checks the contents of the top-level
namespace as a final resort.
* "namespace path" adds a searchpath to the current namespace,
but this is apparently not used as "final resort rule".
Look at the following test script, which is pure tcl:
- the namespace ::tst contains two procs, f-1 is
namespace-imported to top, f-2 not (just
namespace-pathed).
- Both are seen by a toplevel "info command",
both can be executed on top.
- in the ::app-namespace, we have no
namespace path. We can call f-1, but not f-2
===================================
namespace eval ::tst {
proc f-1 {} { return f-1 }
proc f-2 {} { return f-2 }
namespace export f-1 f-2
}
namespace path tst
namespace import tst::f-1
puts f-1=[namespace which f-1]
puts f-2=[namespace which f-2]
puts "we see: [info command f-*]"
namespace eval ::app {
proc foo {} {
puts [namespace current]//[namespace path]
puts f-1=[namespace which f-1]
puts f-2=[namespace which f-2]
f-1
f-2
}
}
::app::foo
===================================
Exactly the same happens in "a::b tst", since "::a"
is an object with object-specific methods and
establishes a tcl namespace.
% Object create a
::a
% Object create a::b
::a::b
% a public method tst args {puts [self]};
::a::tst
% a::b public method tst args {puts [self]};
::a::b::tst
% a tst
::a
% a::b tst
::a::b
%
One could add a namespace path to "::a", but
an application writer does most probably not
like to do this. One could automatically mangle
the default namespace paths (or use special
resolvers) from nx/xotcl, but that could as well
lead to surprising behavior....
Hope, this explains the observed behavior...
-gustaf neumann
PS: namespace path came already with tcl 8.5
Date: Fri, 29 Oct 2010 09:56:23 +0200
Dear victor,
There is a difference/asymmetry between
"namespace path" and "namespace import"
* "namespace import" creates cmd-stubs in the actual namespace
(if issued on "::", in the top-level namespace). The
default rule
for function resolving checks the contents of the top-level
namespace as a final resort.
* "namespace path" adds a searchpath to the current namespace,
but this is apparently not used as "final resort rule".
Look at the following test script, which is pure tcl:
- the namespace ::tst contains two procs, f-1 is
namespace-imported to top, f-2 not (just
namespace-pathed).
- Both are seen by a toplevel "info command",
both can be executed on top.
- in the ::app-namespace, we have no
namespace path. We can call f-1, but not f-2
===================================
namespace eval ::tst {
proc f-1 {} { return f-1 }
proc f-2 {} { return f-2 }
namespace export f-1 f-2
}
namespace path tst
namespace import tst::f-1
puts f-1=[namespace which f-1]
puts f-2=[namespace which f-2]
puts "we see: [info command f-*]"
namespace eval ::app {
proc foo {} {
puts [namespace current]//[namespace path]
puts f-1=[namespace which f-1]
puts f-2=[namespace which f-2]
f-1
f-2
}
}
::app::foo
===================================
Exactly the same happens in "a::b tst", since "::a"
is an object with object-specific methods and
establishes a tcl namespace.
% Object create a
::a
% Object create a::b
::a::b
% a public method tst args {puts [self]};
::a::tst
% a::b public method tst args {puts [self]};
::a::b::tst
% a tst
::a
% a::b tst
::a::b
%
One could add a namespace path to "::a", but
an application writer does most probably not
like to do this. One could automatically mangle
the default namespace paths (or use special
resolvers) from nx/xotcl, but that could as well
lead to surprising behavior....
Hope, this explains the observed behavior...
-gustaf neumann
PS: namespace path came already with tcl 8.5