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

Re: Working Group Proposal

From:
Hugo
Date:
July 25, 2000 10:18
Subject:
Re: Working Group Proposal
Message ID:
200007251320.OAA03802@crypt.compulink.co.uk
In <200007251236.OAA01996@gandalf.local>, marcel@codewerk.com writes:
:In message <Pine.LNX.4.10.10007242215550.25520-100000@tuatha.sidhe.org>,
: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



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About