in reply to Should we have PerlC and PRE?
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).
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: Should we have PerlC and PRE?
by bart (Canon) on Dec 08, 2002 at 18:38 UTC |