* Tom Christiansen <[EMAIL PROTECTED]> [2008-11-27 11:30]:
> In-Reply-To: Message from Darren Duncan <[EMAIL PROTECTED]>
> of "Wed, 26 Nov 2008 19:34:09 PST." <[EMAIL PROTECTED]>
> > I believe that the most important issues here, those having
> > to do with identity, can be discussed and solved without
> > unduly worrying about matters of collation;
>
> It's funny you should say that, as I could nearly swear that I
> just showed that identify cannot be determmined in the examples
> above without knowing about locales. To wit, while all of
> those sort somewhat differently, even case-insensitively, no
> matter whether you're thinking of a French or a Spanish
> ordering (and what is English's, anyway?), you have a a more
> fundadmental = vs != scenario which is entirely
> locale-dependent.
>
> If I can make a "RESUME" file, ought I be able to make a
> distcint "r\x{E9}sum\x{E9}" or "re\x{301}sume\x{301}" file in a
> case-ignorant filesystem?
That’s for the file system to know, not Perl 6. Trying to unify
this in any way on the side of Perl is, in my regard, a fool’s
errand. If the file system is case insensitive, then it will make
the call in whatever way it deems correct, and it’s not for us to
worry about all the possible ways in which all possible current
and future file systems might answer such questions.
Furthermore, from the point of view of the OS, even treating file
names as opaque binary blobs is actually fine! Programs don’t
care after all. In fact, no problem shows up until the point
where you try to show filenames to a user; that is when the
headaches start, not any sooner.
To that, the right solution is simply not to roundtrip filenames
through the user interface; instead, keep both the original octet
sequence as well as the decoded version, and use the decoded
version in UI but refer back to the pristine original when the
user elects, via UI, to operate on that file.
As far as I am concerned, if Perl 6 has a distinction between
octet strings and character strings, then all that’s required is
to have filenames returned from OS APIs come back as octet
strings, keeping the programmer from forgetting to deal with
decoding issues. The higher-level problems like sorting names in
a locale-aware fashion will be solved by the CPAN collective much
better than any boil-the-ocean abstract interface design that the
Perl 6 cabal would produce – if indeed these are real problems at
all in practice.
All that’s necessary is to design the interface such that it
won’t obstruct subsequent “userland” solution approaches.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
