Re: [TCLCORE] TIP#339: Case-Insensitive Package Names

[<dg...@us...>]

Finally got around to reading the proposal
to (partially) shift [package] to using case
insensitive names.  Gonna sleep on it before
commenting extensively.

Meanwhile, it might help me if there were
some example advice of how both application
authors who are using packages, and package
authors would be recommended to modify their
code to make best use of the proposed changed
commands.

For example, if I distribute a script for
users to run, but not in any kind of starkit,
just a plain script.  It relies on having its
required packages and Tcl installed, and I
know it works when deployed to common Tcl
environments (like an ActiveTcl install)
because I know those environments include
the packages I use and I've been careful to
get all the names of all the packages I use
fully case correct.

Now when my users start using Tcl 8.6, all
my [package require]'s will be converted to
case insensitive searches, which creates a 
risk that the wrong package will be found and
break my app.  The TIP offers a -strict option
I can use to protect my program from this
risk, but if I use that, I'm locked out of
continuing to support Tcl 8.5 or even Tcl 8.4
environments that may still be perfectly sufficient
for my program.

Am I missing something?  Is there some better
migration plan I'm not seeing?

One more fairly general question for tonight.
Was any consideration given to a more radical
idea of moving directly to fully case insensitive
package names.  No -strict offerings.  No storing
of the particular case passed to [package provide].
Just [string tolower] everything on the way in.
Let the (allegedly rare) conflicts cause their
breakage in a loud and unmistakable way right away.
Clean up the mess with some renamings, and move
on so that years from now there's no lingering
dealing with multiple modes governed by -strict.
If this was considered, why was it rejected?

Hmm... following that up a bit longer than I planned,
couldn't that be offered and complete compat for
the existing [package] also be maintained simply
by adding a new command that wraps
the existing [package] with added [string tolower]s?

In fact, convert the [::package] command into an
ensemble and then redirect the subcommands either
to their original existing implementation, or to a new
set that wraps all name arguments with the [string tolower]
command to convert each package name into the canonical
name in the nocase equivalence class of the original name.

Supply a convenience subcommand [package match] to 
perform the ensemble redirecting operation for us,
with [package match case] and [package match nocase]
as the two modes  giving the app control over
whether the interp will recognize case in package names
or not.  Make a default choice (I'd choose
[package match case] as the default myself, since
it better keeps our usual promises of incompatibilities
kept as small as we can reasonably manage).  The
rare resetting of the [package match] mode would
both redirect the ensemble *and* sweep through the
package database correcting it to the new assumptions
as best it can.  This might mean a restriction to one
way mode shifting (can make it less demanding, but not
more so), similar to the way [package prefer] can shift
from "stable" to "latest" but can't go back again.

For the C API?  Just leave it alone.  Require C
programmers to get their package name arguments right.
We make them tend to ugly details like encodings.  They
can handle case.

I suspect I'm missing some detail in the [package unknown]
interface that needs further tending to fully flesh out
this alternative, but TIP 339 as written is already 
proposing to incompatibly rewrite that.  Could be as simple
as passing the [package match] mode as an argument.

One (semi-wild?  (hey, it's late here)) thought on
future expansion:  case is not the only thing that
causes confusion in otherwise similar names.  The
package names "a" and "A" are similar, but so are
the names "a" and "Á".  Why not treat them the same
too?  I can imagine adding more keywords to [package match]
to modify the equivalence classes of strings that would
govern the reduction of the name arguments ultimately
passed to the existing [package] machinery.

With that I bid you zzz.

DGP