Donald G Porter wrote:
>  This mismatch between apparent existence, yet non-membership in the set
>  of exported commands (due to actual non-existence), was the same dilemma
>  faced by [namespace import].  That issue was resolved by having [namespace
>  import] do a semi-secret [auto_import] evaluation as part of its operations.
>  I'm not a fan of that solution, but it does illustrate that the conceptual
>  mismatch confronting us here is not new.
[... using -unknown to make it happen ...]

I'd actually be tempted to make use of the -subcommands option to the ensemble
in such a situation, though there is a clear problem with that in that it
precludes the simple adding of extra commands to the ensemble just by defining
and exporting them in the correct namespace.  TIP#140 is possibly part of the
solution to this.

>  Perhaps in time, with feedback from users, greater support for this
>  scenario might be the subject of a future TIP.
>  
>  Of course, another alternative is for packages like control to reexamine
>  whether there's any real benefit to using auto-loading in the first place.

Of course, it doesn't feel like the control package is really conceptually
suitable for ensemblification in the first place.  The various commands within
it are probably better off not being grouped together in that way; adding a
"control" prefix word would just increase confusion.  If we contrast with the
base64 package in Tcllib, that would gain in coherence through the use of an
ensemble.

Donal.
-- 
Donal K. Fellows   http://www.cs.man.ac.uk/~fellowsd/   donal.fellows@[...].uk
-- Prices aren't rising - discounts are falling! It's WalMart-in-reverse! I'm
   not spending more, I'm saving less!  -- Chris Ahlstrom <ahlstromc@[...].com> 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core