http_accept was placed in the global namespace in 2.0.5 and in the ::rivet
namespace in the code in 'trunk'. The difference is motivated by the fact
that the whole command set in 'trunk' had been moved to the ::rivet
namespace
On Thu, Jul 5, 2012 at 3:56 PM, Harald Oehlmann <harald.oehlm...@elmicron.de
> wrote:
> I would like, if at least all new commands are created in the namespace
> "::rivet".
>
> http_accept is new and is in the main namespace.
>
>
> I would propose to add to the file:
> <code>
> namespace eval ::rivet {
> namespace export http_accept
> }
> proc ::rivet::http_accept ...
>
>
yes, it's done so. Actually there is a redundant ::rivet scope
qualification in the procedure in http_accept.tcl. Harmless but I will
removed anyway you can check it out at
trunk/rivet/tclrivet/http_accept.tcl. Only exceptions are commands
encode/decode from the package RivetEntities. They are in the ::rivet
namespace also in branches/2.0
> namespace import rivet::http_accept
> </code>
>
> This would imply, that the function may be accessed by two names:
> http_accept
> rivet::http_accept
>
> IMHO, the future goal is to have all rivet commands within the rivet
> namespace.
> By this syntax, I may already use "rivet::http_accept" and a future
> change to no auto-export would be harmless to me ;-)
>
> Just some thoughts,
> Harald
>
>
if rivet was configured with ./configure ....
--enable-import-rivet-commands (default) the whole command set in
tclrivet/ and commands implemented in rivetCore.c are automatically
imported into the global namespace (valid in trunk, not existing in
branches/2.0). So you may not realized it because the import is implicit by
default, but commands are already in ::rivet for code to be released as
2.1. With --disable-import-rivet-commands you have to import the command
set yourself. Configuring with --disable-rivet-commands-export makes also
the command set not exported, therefore you must access it using the FQ
names
-- Massimo
