in reply to What modules should be added to the corelist?

I would vote for some module that gives us access to the parser. There are a lot of great modules on CPAN that need to do source-filter type of things. Damien Conway went to herculean lengths to parse perl with regexes, and make many of these modules possible, but I don't think he should have needed to. Perl ought to come with a way to localize the state of the parser and iterate the language structure of a given sample of code. This way, every version of perl would be the official source on what it parses, and how, and make all sorts of CPAN modules easier and less error-prone with less dependency bloat.

Aside from that, I'd say some kind of Path::Tiny module, but one which solves the unicode filename problem at the same time. For a language that prides itself on shorthand notations, it's embarrassing to have the file operations look like the C library when it's one of the single most common needs for scripting. My preferred solution would be my proposed enhancement of the "VFS" module, but I didn't find enough tuits to get that moving.

  • Comment on Re: What modules should be added to the corelist?

Replies are listed 'Best First'.
Re^2: What modules should be added to the corelist?
by choroba (Cardinal) on Aug 06, 2024 at 22:09 UTC
    > one which solves the unicode filename problem at the same time

    What about Sys::Binmode combined with Path::Tiny?

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
      I hadn't seen Sys::Binmode - that's interesting. It only solves half the problem though. From its own documentation:
      Of course, in the end, we want mkdir() to receive 6 bytes of UTF-8, not 4 bytes of Latin-1. To achieve that, just do as you normally do with print(): encode your string before you give it to the OS. 
      use utf8;
use Encode;
 
mkdir encode("UTF-8", "épée");

      [download]

      That code is what you want on modern Linux systems, but who wants to write that everywhere? Meanwhile, writing that breaks Win32 support, in most cases. Perl does not currently have *any* cross-platform solution for this problem.

      My point is that a person using file paths on a modern system wants to work with unicode, not mess with knowing how to encode filenames for their platform. Perl has great support for *handling* unicode, but the user experience for unicode filenames (especially on windows) is complete brokenness. I see no way to fix it while preserving back-compat, and the only solution seems to be wrapping the problem inside a module. If a module did fix the problem, then it should be core, because this is an intrinsic problem with perl that *needs* a fix.

      On a sidenote, I'm baffled why Perl is so popular in Japan. I would think they'd be up against this problem nonstop, as opposed to most of Europe who can get by with Latin-1 or variants.

[reply]
[d/l]

In Section Meditations