Re: [PHP-DEV] Re: ini-parsing, double quotes, windows in 5.3
On 06.09.2008, at 11:42, Jordi Boggiano wrote: On Sat, Sep 6, 2008 at 2:15 AM, Scott MacVicar <[EMAIL PROTECTED]> wrote: Stanislav Malyshev wrote: No, the main argument is that it would break people's configs, and for no good reason at all (nobody really needs \n's in their paths). This code is used in parse_ini_file() where it is possible that escapes would be used legitimately, it's not all about paths. This means that not only php.ini will fail - although that is indeed easy to notice - but also any application using ini files might break in a much less obvious manner, right ? It's something that might need to be taken into account. Seems to me like we should consider delaying this fix to 6.0. I agree with Pierre that its probably not a good idea to introduce special handling here and there. As for the error handling, Pierre mentioned that Jani did some tweaks there too. Could someone explain to me what kind of error handling is out into place? If we throw a nice error message for all cases where someone is using \t, \n etc incorrectly inside a php.ini, I think it will not be such a big deal at upgrade time. But still it seems like something we might want to hold off until 6.0, considering that the bug that was fixed did not affect that many users (just a guess). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Making ereg extension optional ?
On 12.09.2008, at 19:16, Pierre Joye wrote: hi, On Fri, Sep 12, 2008 at 6:21 PM, Arnaud Le Blanc <[EMAIL PROTECTED]> wrote: Hi, PHP now builds and works without ereg, is it planed to make it optional ? It is planed to drop it so I suppose optional can be a first step. I remember something about adding a BC layer using pcre, I'm not sure if it is done yet. However I would not do it in 5.x. I think Andrei was pondering doing such a BC layer for PHP6, but I dont think this has been done yet. I think there were still discussions about if its feasible at all. This also means that there were discussions about if to even drop it, but I think we agreed on dropping it in the end, so I guess using ereg should throw an E_DEPRECATED in 5.3? I am not sure if we should make it optional in 5.3 though. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Making ereg extension optional ?
On 12.09.2008, at 19:16, Pierre Joye wrote: hi, On Fri, Sep 12, 2008 at 6:21 PM, Arnaud Le Blanc <[EMAIL PROTECTED]> wrote: Hi, PHP now builds and works without ereg, is it planed to make it optional ? It is planed to drop it so I suppose optional can be a first step. I remember something about adding a BC layer using pcre, I'm not sure if it is done yet. However I would not do it in 5.x. I think Andrei was pondering doing such a BC layer for PHP6, but I dont think this has been done yet. I think there were still discussions about if its feasible at all. This also means that there were discussions about if to even drop it, but I think we agreed on dropping it in the end, so I guess using ereg should throw an E_DEPRECATED in 5.3? I am not sure if we should make it optional in 5.3 though. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
On 12.09.2008, at 23:35, Greg Beaver wrote: Marcus Boerger wrote: Hello Greg, please don't OK. Nice working with you Marcus, this is high class stuff. I'm glad to see the work I'm doing is taken so seriously. Greg, as you can see several people think its better to ensure that namespace/use statements are always at the top. This is all Marcus was expressing in his "german straight to the point" kind of way. That being said, its awesome that you are making sure that when we are discussing namespaces, that we can talk about what behavior we want, without having to wonder if its doable or not. This is very much appreciated! regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Making ereg extension optional ?
Hi Lukas, Am Samstag, den 13.09.2008, 10:44 +0200 schrieb Lukas Kahwe Smith: > This also means that there > were discussions about if to even drop it, but I think we agreed on > dropping it in the end, so I guess using ereg should throw an > E_DEPRECATED in 5.3? I totally support this and would even do the necessary changes if we reach a consensus here. cu, Lars -- Jabber: [EMAIL PROTECTED] Weblog: http://usrportage.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
Hello Greg, Friday, September 12, 2008, 11:35:11 PM, you wrote: > Marcus Boerger wrote: >> Hello Greg, >> >> please don't > OK. Nice working with you Marcus, this is high class stuff. I'm glad > to see the work I'm doing is taken so seriously. Args, sorry if you got this wrong. I think you did some very nice work in namespace and other areas. Just this specific feature is something I don't like at all. Hence 'please' don't do it. And there is no more argument to come... not other than I don't like it. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorderissues)
Hi! In other words, there is simply no comparison. Userspace class usage outnumbers internal class usage by an order of magnitude in typical OO PHP code. I didn't claim userspace class usage outnumbers internal class usage or otherwise. What I claimed is that since we have a lot of files (framework has 1821, as you very helpfully pointed out) and those use 950 instances of internals classes, application using Framework has big chance to "score" hundreds of uncacheable autoloads. And that is not counting user code, which would add to the problem. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ini-parsing, double quotes, windows in 5.3
Hi! As for the error handling, Pierre mentioned that Jani did some tweaks there too. Could someone explain to me what kind of error handling is out into place? If we throw a nice error message for all cases where someone is using \t, \n etc incorrectly inside a php.ini, I think it I have changed the code already so \LETTER is not recognized in php.ini, as it was in 5.2. I do not see any reason for using \n inside php.ini (as far as I understand, in very unlikely case you ever need linefeed - you've got the real one inside "") but there are very real cases where \n can be in windows pathes. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorderissues)
Stanislav Malyshev wrote: > Hi! > >> In other words, there is simply no comparison. Userspace class usage >> outnumbers internal class usage by an order of magnitude in typical OO >> PHP code. > > I didn't claim userspace class usage outnumbers internal class usage > or otherwise. What I claimed is that since we have a lot of files > (framework has 1821, as you very helpfully pointed out) and those use > 950 instances of internals classes, application using Framework has > big chance to "score" hundreds of uncacheable autoloads. And that is > not counting user code, which would add to the problem. Right, and since you pointed out this limitation and then found another example that has the same problem that cannot be solved (non-autoload with load order determining what classname is instantiated), that invalidates any possible approach. I was trying to say that this leaves us with only 1 choice, which is whether to use the name resolution you proposed or stick with the current one. Currently we have: 1) check current namespace 2) check internal 3) autoload if possible 4) fail I remind all of the name resolution for classes that you proposed: 1) check current namespace 2) autoload if possible 3) fail Since my little script proved that the ratio of userspace vs. internal classes heavily favors userspace classes, this load order makes sense. However, I want to point out that it doesn't take a script to prove that the ratio of userspace functions vs. internal functions is exactly the opposite (far more internal functions vs. userspace functions), so I propose we have separate name resolution for classes and functions classes: 1) check current namespace 2) autoload if possible 3) fail functions: 1) check current namespace 2) check internal 3) fail Load order would matter for functions, but the risk is worth the benefit. I believe the initial implementation of namespaces had this order for classes, so Dmitry's first patch would have the necessary changes. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
