TIP #261: Return Imported Commands from [namespace import]
Donal K. Fellows
long. I have no good excuse.]
TIP #261: RETURN IMPORTED COMMANDS FROM [NAMESPACE IMPORT]
============================================================
Version: $Revision: 1.2 $
Author: Martin Lemburg <martin.lemburg_at_gmx.net>
State: Draft
Type: Project
Tcl-Version: 8.5
Vote: Pending
Created: Tuesday, 20 December 2005
URL: http://purl.org/tcl/tip/261.html
WebEdit: http://purl.org/tcl/tip/edit/261
Post-History:
-------------------------------------------------------------------------
ABSTRACT
==========
This TIP describes a mechanism for easily finding out the list of
commands in the current namespace that have been imported from other
namespaces.
RATIONALE
===========
While writing a profiling and introspection module for our C++/Tcl
application, I searched for ways to query all the exported and imported
commands of a namespace.
Although I found the introspection functionality for discovering all
exported commands of a namespace using *namespace export* in the
exporting namespace, I found no way to query all imported commands
inside the importing namespace.
The documentation of *namespace import* said nothing about the
behaviour, if no arguments were given, and testing *namespace import*
without arguments resulted in nothing, in a no-op.
Prompted by this, I started a thread in <URL:news:comp.lang.tcl> which
goes into more detail
[<URL:http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/9fb246cf65aba54f?tvc=1>].
What seems to be more logical to me would be to change the no-op
behaviour of *namespace import* to be comparable to *namespace export*,
and return all imported commands inside the namespace *namespace
import* is executed in.
As an example...
* to get all exported commands of a namespace ::exportingNspc:
namespace inscope ::exportingNspc {namespace export}
* to get all imported commands of the namespace ::importingNspc:
namespace inscope ::importingNspc {namespace import}
CONSEQUENCES
==============
The only consequence I know is, that old scripts using the no-op
*namespace import* suddenly will return a list, probably filled with
names of imported commands. That's all.
Because of the fact, that *namespace import* never returned values, no
script should really break, thus no script should require values from
this command.
PROPOSED CHANGE
=================
The result of *namespace import* without arguments shall be a list of
all commands that have been imported into the current namespace.
As a convenience, if the new optional argument *-origins* is given in
addition, the result shall instead be the list of where each of those
commands was imported from, with a one-to-one correspondence in the
order of results from the *namespace import* and *namespace import
-origins* variants. It will be an error to use the *-origins* option
with additional arguments. Note that this is a convenience, and could
be done with the *namespace origin* command, like this:
proc namespace_import-origins {} {
set result {}
foreach cmd [uplevel 1 namespace import] {
lappend result [uplevel 1 [list namespace origin $cmd]]
}
return $result
}
IMPLEMENTATION
================
A patch and further discussion of the implementation decisions are
available on SourceForge
[<URL:http://sf.net/tracker/?func=detail&aid=1437008&group_id=10894&atid=310894>].
COPYRIGHT
===========
This document has been placed in the public domain.
-------------------------------------------------------------------------
TIP AutoGenerator - written by Donal K. Fellows
MartinLemburg@UGS
Best regards
Martin Lemburg
UGS - Transforming the Process of Innovation
Ulrich Schöbel
Nice and useful TIP.
One thing I don't like is the -origin option. Wouldn't it
be easier to have 'namespace import' return a list of
imported name / original name pairs, or alternatively
a list of lists of such pairs?
My 2c.
Kind regards
Ulrich
MartinLemburg@UGS
> One thing I don't like is the -origin option. Wouldn't it
> be easier to have 'namespace import' return a list of
> imported name / original name pairs, or alternatively
> a list of lists of such pairs?
A really nice idea!
I haven't thought of this yet.
My idea was to reduce the amount of work to have both the origin of an
exported and the exported command itself without the need to create a
new procedure.
And your suggestion matches this probably much better than the
"-origin" option.
But on the other side ... every thing that could be done in tcl and
does not need to be done in the core ... some people prefer to keep the
core as slim as possible!
So the example above in the TIP ...
proc namespace_import-origins {} {
set result {}
foreach cmd [uplevel 1 namespace import] {
lappend result [uplevel 1 [list namespace origin $cmd]]
}
return $result
}
... is for some developers the right way, instead of tweaking the core
to return the origins, too!
IHMO the core should make the work and the usage of tcl as easy as
possible. But I'm not sure, whether this or that solution really helps
in both cases to easy up the work and the usage!
Your suggestion to return both the exported command (origin) and the
imported command creates probably much more data (noise) than needed,
so that some developers may be forced to filter this data. (more work
and not easier to use)
Otherwise - some developers find what they want with a minimum of work!
My suggestion to use the option "-origin", was about to help developers
to get the imported commands or their origins, so to get both only two
calls would be needed.
There would be no need to filter the result, to filter out "noise"!
And there would be no need to create an extra procedure to collect all
the origins of the exported commands.
Ok - there could be a wiki page with a contest of the best and fastest
origns collector procedure and this could be really fun, but why must
developers create such basic functionality, if it is so easy to
implement into the core?
There other areas, discussed here in the newsgroup during the last
weeks, where the discussion was (in my eyes) about to implement basic
functionality into the core, where some people like this, and some
people said, that everybody can do his own solution, that the core has
to be slim!
But ... I was never a friend of reinventing the wheel!
I hope this will be discussed intensively!
Best regards,
Ulrich Schöbel
fine that you like my proposal.
Pondering your objections concerning usage of either implementation,
why not take it all? Just implement three options
-origin returns a list of original names,
-target returns a list of imported names,
-both (grrh, pleas find a better name) follows my suggestion.
One of them, the most frequently used, should be the default
when no option is given.
If this TIP is included in the core (I hope so) it will extend
the core size, of course. The few lines of extra code to implement
all the above options will certainly not make the core fat.
Good luck with your TIP.
Kind regards
Ulrich
Don Porter
>> be easier to have 'namespace import' return a list of
>> imported name / original name pairs, or alternatively
>> a list of lists of such pairs?
This would interfere with composition with [namespace forget],
like so:
# Forget all my imports
namespace forget {expand}[namespace import]
For that to work, you want [namespace import] to return a list
of simple imported command names.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Ulrich Schöbel
see my latest posting. Making -target the default solves
this problem.
Kind regards
Ulrich
Don Porter
> see my latest posting. Making -target the default solves
> this problem.
But not the problem that adding switches to commands that already
accept an aribtrary number of arguments is at best awkward and
somewhat incompatible. The use case needs to be more compelling
to justify it, IMHO.
Just keep it simple. Let [namespace import] with no args return
the simple names of imported commands. If you want the original
names, then compose with [namespace origin].
Ulrich Schöbel
> Ulrich Schöbel wrote:
>> see my latest posting. Making -target the default solves
>> this problem.
>
> But not the problem that adding switches to commands that already
> accept an aribtrary number of arguments is at best awkward and
> somewhat incompatible. The use case needs to be more compelling
> to justify it, IMHO.
>
> Just keep it simple. Let [namespace import] with no args return
> the simple names of imported commands. If you want the original
> names, then compose with [namespace origin].
Yes, you're right. Thinking about Martins -origin my attention
was drawn away from the original purpose of namespace import.
Kind regards
Ulrich