[rt.cpan.org #106144] [Patch] Preload dependencies for File::BOM

[email protected] ("Shawn Laffan via RT")
Newsgroups perl.par
Message-ID <[email protected]>
Thu Jul 30 05:02:28 2015: Request 106144 was acted upon.
Transaction: Correspondence added by SLAFFAN
       Queue: Module-ScanDeps
     Subject: [Patch] Preload dependencies for File::BOM
   Broken in: (no value)
    Severity: (no value)
       Owner: Nobody
  Requestors: [email protected]
      Status: open
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=106144 >


On Thu Jul 30 03:31:22 2015, RSCHUPP wrote:
> On 2015-07-29 19:42:33, SLAFFAN wrote:
> > Actually, if you agree that the Encode::* modules do need to be
> > preloaded then it should be under Encode or Encode::Config, not
> > File::BOM.
> 
> Well, adding
> 
> 'Encode.pm' => 'sub',
> 
> to %Preload will pack ALL of them for a whopping 21 MB of stuff for
> anyone
> who just wants to
> 
> use Encode qw(encode decode);
> ...
> $string = decode("utf8", $bytes);
> 
> So I'm hesitant to do that. If someone knows in advance which
> encodings they need
>  they can add an appropriate -M option to their pp command. If they
> want to be
> flexible (e.g. program takes the encoding as input), this could get
> cumbersome, though.
> 
> There was once a suggestion on the list to add an option to pp that
> would mean
> "include Foo.pm and everything below Foo/". Implementation would be
> almost trivial
> (just call _glob_in_inc("Foo.pm")), the problem is to come up with a
> good name
> for this option.
> 
> Cheers, Roderich
> 
> 

That's a fair point about the size surprise.  21MB isn't that big these days, but it would be excessive for a simple application.

The "everything below Foo" option could possibly be added to pp by adding wildcard or regexp handling to the -M argument, similar to --add in perlapp.  http://docs.activestate.com/pdk/9.4/PerlApp.html#perlapp_top


Coming back to File::BOM, do you want a revised patch for it?

Regards,
Shawn.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.