Re: Working Group Proposal
[email protected] (Hugo)
| Newsgroups | perl.bootstrap |
|---|---|
| Message-ID | <[email protected]> |
In <[email protected]>, [email protected] writes: :In message <[email protected]>, :Dan Sugalski writes: :>On Mon, 24 Jul 2000, Derek J. Balling wrote: :> :>> I'll just say that "I disagree". I don't think you should EVER have :>> to recompile your perl binary to get something a program author :>> thought would be available in THEIR perl binary. :> :>I strongly disagree as well. Maybe (*maybe*) particular backends will have :>well-defined optional pieces missing (like, say, dynaloading, or the :>lexer), but that's as far as I'd like to go. : :<AOL>Me too</AOL>. : :We wouldn't want to go back to the pre-modular Apache or kernel, do :we? Or maybe recompile Java to be able to use inner classes? Recompile :everything just to get one feature in, then rewrite some modules because :they were written with a different feature set of Perl in mind, etc. It :just opens up a can of worms. : :Now if certain features could be implemented as modules, like overriding :(for example) 'open' to accept URLs, that'd be different. Or if you could :restrict certain things using pragmas. If the module isn't available on :a platform (Palm, etc.), then you can't use that feature on that platform. While it is useful for the default to permit the dynaloading of all optional features, it makes sense also to allow sites to implement a policy by turning things off irretrievably - in some situations, it makes a lot of sense to have different functionality available to different people, accessed by way of different perl builds accessible through different access control lists. It is a lot easier to trust a subperl binary that _has_ no mechanism to support (say) system() than a generic perl merely _configured_ not to allow it. In general though, I do agree: and I'd like to see both parser and runtime sufficiently either flexible or replaceable to be able to consider the option of supporting all the 5.6.0 (or whatever) cruft we plan to throw out; to make supporting legacy perl code as simple as adding (say) a 'use 5.6.0' statement at the top. Hugo