| Newsgroups |
perl.bootstrap |
| Message-ID |
<[email protected]> |
In message <[email protected]>, Hugo writes:
>In <[email protected]>, [email protected] 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
comp.lang.perl.moderated?
Marcel