AG>> but I think it'd be nice to brainstorm about this to see how we can AG>> solve this, maybe for 5.1? If regex isn't required by the core that's AG>> one of the first things I'd like to see disabled when building with AG>> --disable-all. I think ext/standard should maybe be split up into AG>> two, the first ext/core and the second ext/standard where ext/core is AG>> the stuff which *really* needs to be part of PHP such as strlen(), AG>> file functions and pretty much stuff I didn't list in my list :)
OK, the problem I see here is that such thing would increase PHP platform diversity. And what I mean by that is: Suppose I am writing some PHP application for distribution. And I use some 'weird' functions - meaning, something beyond strlen() and other obviously 'standard' ones. As for now, it is enough for me to say to the user "this application uses MySQL extension" or "this application uses BlaFooBar extension" or "this application uses only standard functions" and it would be completely sufficient for the user to create an environment where the application would run. If we enable the user to individually disable the functions by standard means, the PHP developer would have now to check if the application uses image() and alert the user in the documentation about it - since the user - or his provider or IT stuff - could decide it is "unneeded" and drop it from compiled version. This means more or less everybody needs now to remember which functions are "core" and which are "non-core". Now we have more or less module-level granularity with clear naming so that there's no doubt which module pgsql_connect belongs to. But enabling the user to drop standard functions would create function-level granularity without a good mean for the developer to know even if given function is "removable" or not (except for memorizing the whole list, of course). Certainly, it is possible even now to break the platform by disabling some functions manually, but then it is messing with the code - which is much higher barrier than altering one config option. Most users have no problem writing some configure line but would never touch the code. I'm concerned that this problem of breaking common platform might be more dangerous than the performance benefit. Which, BTW, I estmate as pretty minimal - code space is shared on all modern OSes anyway, so a little extra code doesn't significantly impact scalability, and unused functions usually don't claim data memory - except for, probably, symbol table entries, but this is a small change. With all this said, if some functions like levenstein(), soundex() etc. might be moved to separate extension and this move would be announced, clearly marked, etc. - it might be feasible. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
