Front page | perl.bootstrap |
Postings from July 2000
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 perl...you'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, Mike ----- Original Message ----- From: "horos" <horos@earth.he.net> To: <bootstrap@perl.org> 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 would > use the same sets of defaults, hence executables would work the same everwhere. > > 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 embedding > 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 interpreter > into an application, you may want to limit perl's ability to write to disk. > And so on. > > Monolithic is good, but only up to a certain point. But ultimately you run into > the MS problem, where they try to make 'one size fit all'. I don't want to have > only two sizes to perl: big and humongous. But that is the way it currently > stands... > > Ed