Don't forget that this will only work for pure Perl modules. XS modules get compiled to native object code at build/install time and this is stored in a platform specific dynamically loadable object (DLL or .so).
One of the other posters mentioned HTML::Parser as an example - in fact, HTML::Parser includes an XS component, so only a very small part of it gets compiled to bytecode. Many useful modules are Perl wrappers for C libraries (GUI libraries, DBI/DBD, compression, encryption, etc) and also wouldn't be compatible with your proposal.
But let's go back to the original problem - Perl doesn't allow you to use components without installing them first. Well hello! Write a VB app and you'll have to install both the VB runtime and any ActiveX controls you need on target machines. Java is the same - sure you can package stuff in a JAR file but any class which wraps a native library will need that library installed too. The typical Java response to this problem is to re-implement a library in Java. Even a C app requires you to have the required libraries installed (unless you squander resources and link everything statically).
In reply to Re: Should we have PerlC and PRE?
by grantm
in thread Should we have PerlC and PRE?
by dingus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |