Re: [PHP-DEV] Complete case-sensitivity in PHP
On 4/22/2012 11:32 PM, Galen Wright-Watson wrote: 2012/4/22 C.Koycan5...@gmail.com On 4/21/2012 4:37 AM, Galen Wright-Watson wrote: But, I did not start this thread to discuss such bug fix, because: 1. It does not take a genius to figure it out, and should take minutes to implement for someone experienced in the internals. Given the 10 year span and dozens of comments/complaints on the bug's entry, it's hard to say this issue went unnoticed. So I had to conclude that such fix has quietly been overruled for performance and/or other undisclosed reasons. Why does it matter if a solution is simple? It doesn't matter, you've misunderstood. On the contrary, common sense dictates a simple solution should be applied (considering how deep in the PHP stack we're talking about). And that's what makes me curious and confused about why this bug still exists. See, I'm drawing a conclusion with what little information I have, and stating the reasonings it's based on (first two statements). Overall, that and the item following it were an explanation of why I'm suggesting a major feature change in solution to a specific bug, although noone directly asked me to. If it's already been rejected privately, it's time to bring the reasons into the open (which is why I asked). If not, it should be considered publicly. A comment dated 2002-09-26 on bug's page states the bug is fixed. The next comment dated 2006-02-17 states it reappeared. I don't know who did what 10, 6 years ago but it's been revoked. Why? That was the main reason I deemed this bug not fixable, hence suggest other ways to resolve. The abstract property that makes a locale problematic is obvious. I was looking for specific locales, as they need to be identified for a complete solution. I'm not locale expert. Given the public complaints/bugs we can, in practice, assume this affects Turkish and Azerbaijani only. (I don't know about Kurdish) best regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Extension versions
Heya, It appears that many extensions do not expose proper version information. Here an abstract of the various things I found using the following script: $ for i in `php -m`; do php --re $i | grep $i version; done curl no_version date 5.4.0 dom 20031129 mysqlnd mysqlnd 5.0.10 - 20111026 - $Revision: 323634 $ PDO 1.0.4dev Reflection $Revision: 321634 $ xdebug 2.2.0rc1 As you see it goes from no version at all to proper versions, passing by svn revisions, dates, or a mix of all. In Composer [1] we try to parse all that using ReflectionExtension, to allow people to require some specific version of an extension if they want. Obviously this doesn't work very well when no version or some random revision number is provided. Is there any other way I overlooked to get more version info? If not, can this at least be improved in the future? [1] http://getcomposer.org/ Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension versions
On Mon, 2012-04-23 at 16:47 +0200, Jordi Boggiano wrote: As you see it goes from no version at all to proper versions, passing by svn revisions, dates, or a mix of all. In Composer [1] we try to parse all that using ReflectionExtension, to allow people to require some specific version of an extension if they want. Obviously this doesn't work very well when no version or some random revision number is provided. Is there any other way I overlooked to get more version info? If not, can this at least be improved in the future? For PECL extensions the version number should be fine (or you can hit the package maintainer ;-) ). For core stuff i'd propose to switch to PHP_VERSION as version everywhere. While this can be complicated for extensions which are maintained in both (oci8 for instance) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension versions
+1 for that notice. In fact, Zend API provides extensions a char* to give a hint about the extension version, but I guess no-one has been serious and really used that field as it would have to be. I recently noticed mistakes in ext/mysqlnd_ms as well. I then agree with Johannes, just use PHP_VERSION, and you can think about yourself as safe. Well, at least until a curious setup would compile PHP itself mixing extension versions in the same PHP Core version ... Cheers Julien.P 2012/4/23 Johannes Schlüter johan...@schlueters.de On Mon, 2012-04-23 at 16:47 +0200, Jordi Boggiano wrote: As you see it goes from no version at all to proper versions, passing by svn revisions, dates, or a mix of all. In Composer [1] we try to parse all that using ReflectionExtension, to allow people to require some specific version of an extension if they want. Obviously this doesn't work very well when no version or some random revision number is provided. Is there any other way I overlooked to get more version info? If not, can this at least be improved in the future? For PECL extensions the version number should be fine (or you can hit the package maintainer ;-) ). For core stuff i'd propose to switch to PHP_VERSION as version everywhere. While this can be complicated for extensions which are maintained in both (oci8 for instance) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension versions
On Mon, 2012-04-23 at 18:39 +0200, jpauli wrote: In fact, Zend API provides extensions a char* to give a hint about the extension version, but I guess no-one has been serious and really used that field as it would have to be. Every(*) PECL extension does. (*) The exception proves the rule. I recently noticed mistakes in ext/mysqlnd_ms as well. Mistakes happen. For a version their was a mistake. For 10 other releases it had the correct version number. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On Mon, Apr 23, 2012 at 3:22 AM, C.Koy can5...@gmail.com wrote: On 4/22/2012 11:32 PM, Galen Wright-Watson wrote: 2012/4/22 C.Koycan5...@gmail.com On 4/21/2012 4:37 AM, Galen Wright-Watson wrote: But, I did not start this thread to discuss such bug fix, because: 1. It does not take a genius to figure it out, and should take minutes to implement for someone experienced in the internals. Given the 10 year span and dozens of comments/complaints on the bug's entry, it's hard to say this issue went unnoticed. So I had to conclude that such fix has quietly been overruled for performance and/or other undisclosed reasons. Why does it matter if a solution is simple? It doesn't matter, you've misunderstood. You've misunderstood me. While you may have set out with the goal of discussing making PHP completely case-sensitive, that doesn't preclude others from suggesting fixes for the specific bug you mention. Indeed, some of the first e-mails were around the bug, and not just in the context of case-sensitive PHP. I didn't introduce the custom case conversion solution as a counter-argument to case-sensitive PHP, and I wasn't asking for feedback on that solution in the context of case-sensitive PHP; I was asking for reasons why it wouldn't be a suitable solution for the bug. The only place case-sensitive PHP enters into it was your statement that: As the recent comments on that page indicate, there's not a deterministic way to resolve this issue, apart from eliminating tolower() calls for function/class names during lookup. Hence totally case-sensitive PHP. My proposition shows this is isn't entirely true, and branches off from the original discussion at that point. I'm focusing on fixing the bug, which is a smaller issue than case-sensitivity. Discussion of case-sensitivity can continue without regard to the custom conversion solution. As such, I've changed the subject of this e-mail. Furthermore, going back to your original e-mail, you explicitly stated it was about the bug, making case sensitivity subordinate to it. This post is about bug #18556 (https://bugs.php.net/bug.php?**id=18556https://bugs.php.net/bug.php?id=18556) which is a decade old. I hope you can see why others might take the bug to be the context for case-sensitivity, rather than the other way around. And that's what makes me curious and confused about why this bug still exists. See, I'm drawing a conclusion with what little information I have, and stating the reasonings it's based on (first two statements). Overall, that and the item following it were an explanation of why I'm suggesting a major feature change in solution to a specific bug, although noone directly asked me to. In other words, you jumped to a conclusion. I wasn't asking about possible reasons why custom conversion hasn't been accepted as the solution to this bug. Neither was I asking why you didn't suggest it. I was (and still am) asking for explicit, justifiable reasons as to whether or not it's a suitable solution to the bug. If it's already been rejected privately, it's time to bring the reasons into the open (which is why I asked). If not, it should be considered publicly. A comment dated 2002-09-26 on bug's page states the bug is fixed. The next comment dated 2006-02-17 states it reappeared. I don't know who did what 10, 6 years ago but it's been revoked. Why? That was the main reason I deemed this bug not fixable, hence suggest other ways to resolve. I don't know either, but I'm not about to disregard potential fixes if they haven't been publicly discussed. The regression could just as easily have been a mistake. From looking at the original fix (revision 97040, http://svn.php.net/viewvc?view=revisionrevision=97040, authored by iliaa) and the bug comments, something along the lines of what I'm suggesting has been suggested and even implemented before, but there's no real discussion of it. The original fix (zend_str_tolower_nlc) assumed ASCII, which isn't entirely suitable as there are uppercase characters that it doesn't convert, which suggests yet another reason for the regression, namely that using zend_str_tolower would convert the characters that zend_str_tolower_nlc missed. As for the real reason why the bug reappeared, we can continue on in our historical examination. Revision 99001 ( http://svn.php.net/viewvc?view=revisionrevision=99001, also authored by iliaa) replaced zend_str_tolower with zend_str_tolower_nlc, making all internal Zend case conversion use ASCII. iliaa had this to say about the change (http://news.php.net/php.zend-engine.cvs/478): It appears that there no reason to keep both zend_str_tolower_nlc and zend_str_tolower. zend_str_tolower_nlc can be safely renamed to zend_str_tolower. The places it is used in, do not appear to depend on locale. For people who do need it there is an alternative php function php_strtolower, which they can use, which does respect the locale. So, if there are no
