On Tue, Aug 18, 2009 at 13:10, Jan Ingvoldstad<frett...@gmail.com> wrote:
> On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsen<t...@rapanden.dk>
> wrote:
>
>> My idea with portable by default was only portability for modern Unix and
>> modern Windows. So DOS and VMS limitations would not apply. The problem of
>> enforcing truly "portable" filenames is that the files names get too
>> restrictive and for most applications targeting 98% of systems out there
>> would
>> be enough.
>
> That's a decent enough point, but it may be unwise to ignore legacy
> systems that where Perl 5 is in common use, unless we want to shed
> that userbase. (Mark this down as a "I don't know, and I don't have a
> stake in it, but…)
I completely agree and we might make a p:posix{} or p:strict{} to handle that.
But one thing to remember is that having the default p{} allow characters and
formats that is not supported on VMS or DOS, only means the programmer won't
get a compiler error. In other words he is only a little better off than using
a normal string or Q{}. Also in cases where systems has special requirements
the local version should be used so, fx. VMS would have p:vms{} and DOS
p:dos{}.
The defaults should handle most cases and limiting path's to only ASCII might
be a bit much. For the default path literal to be useful it should work in most
normal cases, and I would say international characters would be a normal case.
What I would like to go for is the lowest reasonable common denominator for the
default p{}, for me at least this is MacOSX, Windows XP, Linux, *BSD, etc.
>
>> With modern Unix/Windows I'm thinking about systems that support and use UCS2
>> or UTF8 and where "." or other common characters does not have special
>> meaning
>> for the filesystem.
>
> We also need to keep in mind the Unicode problems between certain
> unixy platforms (i.e. MacOS X vs. most if not all the rest).
>
> If I recall correctly, the internal Unicode format chosen for Perl 6
> is incompatible with MacOS X, because MacOS X implemented Unicode
> support at a time when the standard as we know it today wasn't
> finalized.
>
> This has bearing on filenames, and MacOS X isn't a small enough
> platform that it can simply be ignored, either.
I guess if this puts limits of what characters can be in file names it should
also go in the default limits. But how Perl 6 stores the Path internally is not
really important, so long as it can be automatically converted with out
changing meaning before it is parsed to the OS. So what we should limit is what
can not be automatically converted.
Regards Troels.
