If this is a pecl module library developers cannot use it and trust that on php 5.n, it just works. That would fork the language in an undesirable way. It should be a core feature, no ini flag, no sometimes-there module.
Sent from my iPhone On Apr 12, 2012, at 10:00 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi, > > 2012/4/13 Yasuo Ohgaki <yohg...@ohgaki.net>: >> Hi, >> >> 2012/4/13 Stas Malyshev <smalys...@sugarcrm.com>: >>> Hi! >>> >>>> If I exclude current code, then introducing script only include will be >>>> preferred one. I preferred dedicated statement for it though. >>>> >>>> include >>>> include_once >>>> require >>>> require_once >>>> script >>>> script_once >>> >>> I have a thought here. To implement script/script_once you don't need it >>> to be a language construct. A function would do just as fine. Why not >>> make an extension having these two functions, put it on PECL and see if >>> people will be using it? >>> For extreme adopters, you could even make php.ini switch that overrides >>> include/require and redirects them to your script functions. Shouldn't >>> be impossible to do, I think. >> >> Good idea. >> >> I think it's possible as a Zend engine module. It may be possible >> as normal module if compiler hook can be used. I guess it is now. >> >> It provides optional security by accident. (Someone called LFI syntax >> error an accident and I like it) I wish the other RFC author >> implement this. >> >> Regards, > > I just briefly read tokenizer code. > We can simply scan tokens and validate then executes. > So it's a very simple module to write. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
