Tcl Source Code

The commands

http::data
http::status
http::code
http::ncode
http::size
http::error
http::cleanup

are all documented, public commands of the
package http.  They should be added to the
[namespace export] list.

Also, the command

http::mapReply

has the form of a public command.  It should either
be documented and [namespace export]ed, or should
be changed to look like a private command.

Documentation http(n) changed to list the exported and non-exported commands. See commit [deb816791ea2deb8].

http::quoteString is an alias of http::mapReply that is both exported and documented.

Logged In: YES 
user_id=80530

We disagree about what should be [namespace export]ed.
(Those who would have "compatbility problems" are getting
the trouble they asked for.  Promiscuous [namespace import]
should be discouraged!)

We agree this is a low priority matter, so no need to
continue the argument.

This discussion has reawakened some thoughts about
improvements to [namespace import] that, after TIPping,
could make everybody happy.  Stay tuned.

Meanwhile, improved documentatation will satisfy me.

Logged In: YES 
user_id=72656

I prefer the documentation route for this one, because the 
other one opens up backwards compatability problems 
(serious ones), where people already have [namespace 
import -force ::http::*], which is likely.

Logged In: YES 
user_id=80530

At the very least, if a public command is not
exported, then the inability to [namespace import]
that command must be documented.  The user of the
http package needs that documentation so he knows
not to attempt [namespace import ::http::error], etc.

I prefer a policy of always [namespace export]ing
all public commands of any package.  If you do not
[namespace export] a command, then users may not
[namespace import] and [rename] it to use it in
the way they choose within their own namespace.

It is true that a [namespace import ::http::error]
into :: would conflict with [::error], but it is
not necessarilly true that a conflict would exist
in any other namespace.  By refusing to 
[namespace export] these commands, you prevent their
import into *any* namespace, just becuase there will
be trouble importing into *one* namespace.

Logged In: YES 
user_id=72656

docs don't justify exporting.  For the above, the obvious 
conflict of 'error' shows the problems of exporting such 
simply named namespaced can't always be exported.