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

Re: Working Group Proposal

July 25, 2000 12:50
Re: Working Group Proposal
Message ID:

In message <>, Hugo writes:

>In <200007251236.OAA01996@gandalf.local>, writes:
>: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.

I would like to continue this discussion; unfortunately, as several
people have pointed out, it is off-topic for this list.

Would you (plural) like to move this discussion over to

Marcel Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About