develooper Front page | perl.bootstrap | Postings from July 2000

Re: Working Group Proposal

Mike Lambert
July 24, 2000 19:43
Re: Working Group Proposal
Message ID:
Well, the example you gave was about putting support for http, ftp, etc, etc
at the COMPILE level. That, imo, is too great of a distinction. Say your ISP
has a non-standard version of're stuck, and it sucks. Rather,
just take the pluggable modules approach...

The open keyword does nothing but delegate. When you pass it a filename, it
loads the 'open::filename' module, and passes it the parameters, which
proceed to open the file for reading in some standard stream format. If I
passed it 'http://', it would open the 'open::http' module which could just
have hooks into the LWP modules or something. With this approach, you can
just install/deinstall the modules, or extend open to include your own
proprietary format by creating a module. A palm-pilot could just not have
those modules exist, and perl could notify them nicely. The user could
choose to use up valuable memory on their networked palmpilot and add the
'open::http' module, or choose not to.

Of course, they'd be installed by default, and the only way to remove them
to create a microperl or minperl would be to remove them manually and
repackage perl or something. I don't think it should be something that's
optional when you install perl.

Just my $0.02,

----- Original Message -----
From: "horos" <>
To: <>
Sent: Monday, July 24, 2000 9:05 PM
Subject: Re: Working Group Proposal

> > >Include keyword 'open' in perl library? [y]
> > > Include support for 'http' in 'open' [y]
> > > Include support for 'ftp' in 'open' [y]
> > > Overload 'open' with other support (https, etc)? [n];
> >
> > Then you could say good-bye to portable Perl scripts.
> >
> > --tom
> well, not necessarily. Likelihood is that at first pretty much everybody
> use the same sets of defaults, hence executables would work the same
> But yes, ultimately there may be more than one group of defaults that make
> sense. If you want to embed perl on a palm-pilot, you really don't need
all the
> cruft that comes along with a full set of perl. Same goes if you are
> an interpreter into apache - lots of places aren't willing to pay the cost
> (in memory) to do this currently. And if you want to embed a perl
> into an application, you may want to limit perl's ability to write to
> And so on.
> Monolithic is good, but only up to a certain point. But ultimately you run
> the MS problem, where they try to make 'one size fit all'. I don't want to
> only two sizes to perl: big and humongous. But that is the way it
> stands...
> Ed Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About