Front page | perl.bootstrap |
Postings from July 2000
In message <200007251320.OAA03802@crypt.compulink.co.uk>, Hugo writes: >In <200007251236.OAA01996@gandalf.local>, marcel@codewerk.com 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? MarcelThread Previous | Thread Next