Re: [PHP-DEV] Re: [RFC] skipping optional parameters
On 04/18/2012 11:04 PM, Stas Malyshev wrote: Hi! default is already a reserved keyword. It's used in switch constructs. So it is safe to use :) Ah, silly me, indeed it is. Then I guess it doesn't hurt to add it as an option. Will do. I can't estimate the amount of breakage, but what about using underscore (literal _) without quotation marks? In functional languages it's sometimes the default match in pattern matching, that's at least a loose conversion and I hope not many people would do define(_, whatever) in their code. The question now is, if create_query(a, _, _, _, true) really looks better... Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] skipping optional parameters
Hi! I can't estimate the amount of breakage, but what about using underscore (literal _) without quotation marks? This one is taken. See: http://us2.php.net/_ -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Property get/set syntax
Hi! If there is no other discussion for this, I'd like to move this to the voting phase, any objects? https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented Sorry, I didn't have time to look into it yet (yes I know it was around for a long time...) in detail. From the quick glance I don't like the read-only/write-only keywords too much but maybe it's ok. It's not clear what automatic implementation is. Could you expand this section and add explanation what actually happens? What would happen if I use $this-property = $a; or $a = $this-property; $a = 1;? What happens if getter/setter function uses the same property it is defined for? What if it uses other property that in turn uses this one? In the last example for overloading, it looks like parent::$Milliseconds = $value; calls parent setter. This looks like static property access but is not. I don't think it's a good thing. What if you also have static class var called $Milliseconds? And especially that later you introduce the same syntax for accessing class properties! How these would work with isset - what !empty($this-Hours) return? What would happen if you do unset($this-Hours)? What happens if you do $this-Hours++ or sort($this-Hours) (assuming $Hours is an array)? These things need to be defined in the RFC too. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Access by siblings of (abstract) protected methods
Hi! In summary: should abstract protected constructors be inaccessible by siblings, as is true of __clone and __destruct? Should __construct, __clone and __destruct always be accessible in relatives, as is true of other methods? Depending on the answers, there could be a documentation issue, or bugs. I've submitted bug #61782 (https://bugs.php.net/bug.php?id=61782) to track the issue with __clone and __destruct. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Property get/set syntax
Hi, Are the dashes acceptable or undesirable? I think without dashes it is more in line with other keywords, like instanceof or insteadof. Because keywords are not case sensitive, one who likes them to be more readable could write them camelCased, for example readOnly, or writeOnly. -- Christoph Hochstrasser http://twitter.com/hochchristoph | http://christophh.net | https://github.com/CHH -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Complete case-sensitivity in PHP
Hi, This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556) which is a decade old. 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. Before opposing with No, this will break a lot of existing code!, note that I'm not suggesting a static permanent change in the engine; rather a runtime option that will need to be enabled (cli option, INI setting), without which PHP will work as before. Since I'm not well versed in the workings of Zend engine, I solicit the wisdom/experience of people in this list: Is this doable in a practical way, without making grand changes in Zend? best regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Property get/set syntax
2012/4/20 Stas Malyshev smalys...@sugarcrm.com: How these would work with isset - what !empty($this-Hours) return? What would happen if you do unset($this-Hours)? What happens if you do $this-Hours++ or sort($this-Hours) (assuming $Hours is an array)? These things need to be defined in the RFC too. My suggestion is to support the same methods for properties as we do for magic class methods: __set, __get, __isset and __unset. All the other operations (sort, ++, ,...) should behave exactly as if it was be implemented with current magic class methods with a usual switch/case statement. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Property get/set syntax
On 2012-04-20, Christoph Hochstrasser christoph.hochstras...@gmail.com wrote: Hi, Are the dashes acceptable or undesirable? I think without dashes it is more in line with other keywords, like instanceof or insteadof. Because keywords are not case sensitive, one who likes them to be more readable could write them camelCased, for example readOnly, or writeOnly. If they are to be keywords, I'd argue we should use the dash variant -- the reason being that with the dash, there can be no conflict with existing constant, variable, or function names. I know I've had a fair number of each named both readonly and writeonly. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Complete case-sensitivity in PHP
On 2012-04-20, C.Koy can5...@gmail.com wrote: This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556) which is a decade old. 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. Before opposing with No, this will break a lot of existing code!, note that I'm not suggesting a static permanent change in the engine; rather a runtime option that will need to be enabled (cli option, INI setting), without which PHP will work as before. Since I'm not well versed in the workings of Zend engine, I solicit the wisdom/experience of people in this list: Is this doable in a practical way, without making grand changes in Zend? It's not just about changes to the engine. If you introduce a runtime option that switches behavior, you then get a portability problem -- code runs fine in one context, but not the other. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Complete case-sensitivity in PHP
Yup - a one time transition would be preferable to that. On Fri, Apr 20, 2012 at 9:13 AM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2012-04-20, C.Koy can5...@gmail.com wrote: This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556) which is a decade old. 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. Before opposing with No, this will break a lot of existing code!, note that I'm not suggesting a static permanent change in the engine; rather a runtime option that will need to be enabled (cli option, INI setting), without which PHP will work as before. Since I'm not well versed in the workings of Zend engine, I solicit the wisdom/experience of people in this list: Is this doable in a practical way, without making grand changes in Zend? It's not just about changes to the engine. If you introduce a runtime option that switches behavior, you then get a portability problem -- code runs fine in one context, but not the other. -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
In past years such switches where deprecated and removed (in 5.3 most of them, in 5.4 finally all that stuff is gone for good). So any solution, involving a switch that modifies how code is executed will hit a wall of resistance. It's the lesson that was learned the hard way. So it may be the case to make PHP case-sensetive. There will be code broken, probably a lot. But that can be fixed, and I personally always write with respect to char case, so that will be no problem for me. 20 апреля 2012 г. 13:20 пользователь C.Koy can5...@gmail.com написал: Hi, 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. 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. Before opposing with No, this will break a lot of existing code!, note that I'm not suggesting a static permanent change in the engine; rather a runtime option that will need to be enabled (cli option, INI setting), without which PHP will work as before. Since I'm not well versed in the workings of Zend engine, I solicit the wisdom/experience of people in this list: Is this doable in a practical way, without making grand changes in Zend? best regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On Fri, Apr 20, 2012 at 12:20 PM, C.Koy can5...@gmail.com wrote: Hi, This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556) which is a decade old. 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. Before opposing with No, this will break a lot of existing code!, note that I'm not suggesting a static permanent change in the engine; rather a runtime option that will need to be enabled (cli option, INI setting), without which PHP will work as before. Since I'm not well versed in the workings of Zend engine, I solicit the wisdom/experience of people in this list: Is this doable in a practical way, without making grand changes in Zend? I'm not sure whether I really get the issue, but as it seems the problem seems to be that PHP is using locale-aware lowercasing functions in the core. Couldn't the issue be fixed by replacing those with local-unaware functions? Why does one have to change PHPs general case sensitivity handling for that? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
Because you can write a function name, say, in Cyrilic and it will just work. 20 апреля 2012 г. 16:47 пользователь Nikita Popov nikita@googlemail.com написал: On Fri, Apr 20, 2012 at 12:20 PM, C.Koy can5...@gmail.com wrote: Hi, This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556) which is a decade old. 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. Before opposing with No, this will break a lot of existing code!, note that I'm not suggesting a static permanent change in the engine; rather a runtime option that will need to be enabled (cli option, INI setting), without which PHP will work as before. Since I'm not well versed in the workings of Zend engine, I solicit the wisdom/experience of people in this list: Is this doable in a practical way, without making grand changes in Zend? I'm not sure whether I really get the issue, but as it seems the problem seems to be that PHP is using locale-aware lowercasing functions in the core. Couldn't the issue be fixed by replacing those with local-unaware functions? Why does one have to change PHPs general case sensitivity handling for that? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
Because you can write a function name, say, in Cyrilic and it will just work. PHP deals with strings on a binary level though. To PHP a function name of Áãç, for example is just a set of 256 bit encoded bytes. So \xc3\x81\xc3\xa3\xc3\xa7 is all it sees, right? I'm not sure I follow what the problem is. Sorry this might not have been sent to the list properly in my last reply. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On Fri, Apr 20, 2012 at 9:01 AM, Sherif Ramadan theanomaly...@gmail.comwrote: Because you can write a function name, say, in Cyrilic and it will just work. PHP deals with strings on a binary level though. To PHP a function name of Áãç, for example is just a set of 256 bit encoded bytes. So \xc3\x81\xc3\xa3\xc3\xa7 is all it sees, right? I'm not sure I follow what the problem is. But in order to be case insensitive, PHP needs to know that strtolower(A) == 'a'. So if you use Cyrilic for userland functions/classes, php needs a cyrillic aware strtolower function. Then the problem is that core classes/functions need to use a plain ASCII strtolower for case insensitivity. So you cannot both write code in cyrillic and interface with plain ASCII internals. One possible, but less than optimal solution is to first try a locale aware strtolower, then try a plain ascii strtolower when looking up symbols. John
Re: [PHP-DEV] Re: Complete case-sensitivity in PHP
On Fri, 2012-04-20 at 09:21 -0400, Tom Boutell wrote: Yup - a one time transition would be preferable to that. Then the question is: Why? What's the benefit from a break? Is there a need to have imagecreatefrompng() next to a ImageCreateFromPNG()? Or is the reason to be a tiny bit faster? Or is the reason to break everything just for consistency? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
But in order to be case insensitive, PHP needs to know that strtolower(A) == 'a'. So if you use Cyrilic for userland functions/classes, php needs a cyrillic aware strtolower function. Then the problem is that core classes/functions need to use a plain ASCII strtolower for case insensitivity. So you cannot both write code in cyrillic and interface with plain ASCII internals. One possible, but less than optimal solution is to first try a locale aware strtolower, then try a plain ascii strtolower when looking up symbols. John I can see the confusion about PHP's case-sensitivity and how it mixes and matches between case-insensitive functions/classes/(arguably even constants), and case-sensitive variable names, for example. Its naming rules are a little bit inconsistent in that regard. I just don't see a point in making it completely locale aware. The fact that you can do soefunc() and SOMEFUNC() and still invoke the same function is a benefit. And I suppose for those using UTF-8 encoded function names it might be convenient to make them case-sensitive as well. I'm not going to argue that it's not. I'm just going to say that it doesn't seem to be a significant problem. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 4/20/2012 6:44 PM, Sherif Ramadan wrote: Its naming rules are a little bit inconsistent in that regard. I just don't see a point in making it completely locale aware. The fact that you can do soefunc() and SOMEFUNC() and still invoke the same function is a benefit. And I suppose for those using UTF-8 encoded function names it might be convenient to make them case-sensitive as well. I'm not going to argue that it's not. I'm just going to say that it doesn't seem to be a significant problem. The lowercase of a multi-byte character is not the lowercase of individual bytes comprising it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On Fri, Apr 20, 2012 at 8:44 AM, Sherif Ramadan theanomaly...@gmail.comwrote: But in order to be case insensitive, PHP needs to know that strtolower(A) == 'a'. So if you use Cyrilic for userland functions/classes, php needs a cyrillic aware strtolower function. Then the problem is that core classes/functions need to use a plain ASCII strtolower for case insensitivity. So you cannot both write code in cyrillic and interface with plain ASCII internals. One possible, but less than optimal solution is to first try a locale aware strtolower, then try a plain ascii strtolower when looking up symbols. John I can see the confusion about PHP's case-sensitivity and how it mixes and matches between case-insensitive functions/classes/(arguably even constants), and case-sensitive variable names, for example. Its naming rules are a little bit inconsistent in that regard. I just don't see a point in making it completely locale aware. The fact that you can do soefunc() and SOMEFUNC() and still invoke the same function is a benefit. Could you elaborate? Aside from making PHP forgiving of typos and overall laziness on the part of the coder, and of course BC notwithstanding, I'm not sure I understand what benefit there is to preserving this inconsistent behavior. And I suppose for those using UTF-8 encoded function names it might be convenient to make them case-sensitive as well. I'm not going to argue that it's not. I'm just going to say that it doesn't seem to be a significant problem. When I was at Microsoft, I got into a little argument with some folks from the Windows division about this very issue-- except, in this case, it was about case-sensitivity in the filesystem. They essentially made the same argument; i.e. Why would you want 'Find.exe' and 'find.exe' to be two separate things?! I countered that I may want to add a library to the PATH that contains a file with the same name, such as UnxUtils. Why would you want to do that?! Windows' find.exe is way better than the Unix one, anyway! And then my brain exploded. Turkish localization notwithstanding (I confess that I know absolutely * nothing* about that lol), one possible use-case could be if you're including an external library/framework that contains a function with the same name but different case. I'm not sure how likely that is, mind you, but I can see that as one potential benefit. Either way, I guess my point is that the arguments for/against this seem to parallel the arguments for Windows-style fso case-insensitivity vs. Unix-style fso case-sensitivity. --Kris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 2012-04-20, Kris Craig kris.cr...@gmail.com wrote:
On Fri, Apr 20, 2012 at 8:44 AM, Sherif Ramadan theanomaly...@gmail.com
wrote:
But in order to be case insensitive, PHP needs to know that
strtolower(A) == 'a'. So if you use Cyrilic for userland
functions/classes, php needs a cyrillic aware strtolower function.
Then the problem is that core classes/functions need to use a
plain ASCII strtolower for case insensitivity. So you cannot both
write code in cyrillic and interface with plain ASCII internals.
One possible, but less than optimal solution is to first try a
locale aware strtolower, then try a plain ascii strtolower when
looking up symbols.
I can see the confusion about PHP's case-sensitivity and how it mixes
and matches between case-insensitive functions/classes/(arguably even
constants), and case-sensitive variable names, for example.
Its naming rules are a little bit inconsistent in that regard. I just
don't see a point in making it completely locale aware. The fact that
you can do soefunc() and SOMEFUNC() and still invoke the same function
is a benefit.
Could you elaborate? Aside from making PHP forgiving of typos and overall
laziness on the part of the coder, and of course BC notwithstanding, I'm
not sure I understand what benefit there is to preserving this inconsistent
behavior.
To make extensible and flexible systems, it's not uncommon to
dynamically determine class and function or method names. This task
is far simpler and less expensive if you don't need to worry about the
casing of these names.
As an example, I often see code like the following:
public function setOptions(array $options)
{
foreach ($options as $key = $value) {
$method = 'set' . $key;
if (!method_exists($this, $method)) {
continue;
}
$this-$method($value);
}
}
This is trivial to implement and understand, and requires no need to
transform the value of $key to an appropriately cased value in order to
ensure the method name exists.
Making method names case sensitive would break a ton of code, and
require a ton of computational overhead as well as validation to make
code like the above work.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
Could you elaborate? Aside from making PHP forgiving of typos and overall
laziness on the part of the coder, and of course BC notwithstanding, I'm not
sure I understand what benefit there is to preserving this inconsistent
behavior.
Kris,
Sorry, first to be clear I made a typo there, but what I'm saying is
PHP currently doesn't care if you do the following:
?php
function Foo() { }
/* these all work the same obviously */
foo(); Foo(); FOO();
?
However, it does care if you do the following:
?php
$foo = 'bar';
$Foo = 'baz';
$FOO = 'quix';
?
I'm not saying I'm in favor of making PHP case-insensitive. I think
it's fine that it is case-sensitive since it deals with mostly
everything on a binary level. I think the fact that it currently does
allow ASCII case-insensitivity for method/function/class/(and
partially constant) names is somewhat confusing though. It should
probably be either all case-sensitive or not. As you can argue that
there seems to be little reasoning behind wanting $foo and $FOO to be
two different things, but hey that's the arguable part.
I can't see much reason to breaking any of this now though. I don't
know about others, but I've rarely ever written or worked with PHP
code where function/method names were in anything other than ASCII and
me or anyone else cared about case-sensitivity there. I say it's fine
the way it is and I don't really see anyone presenting a valid use
case for why it should change.
Just my two cents.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 4/20/2012 8:57 PM, Kris Craig wrote: Turkish localization notwithstanding (I confess that I know absolutely * nothing* about that lol), one possible use-case could be if you're including an external library/framework that contains a function with the same name but different case. I'm not sure how likely that is, mind you, but I can see that as one potential benefit. Either way, I guess my point is that the arguments for/against this seem to parallel the arguments for Windows-style fso case-insensitivity vs. Unix-style fso case-sensitivity. Java, C#, Python, Ruby... are all case-sensitive. This is not a feature to be (mis-)used so that one can have a function named myfunc() and MyFunc() in the same code base. Case-insensitive class/function/interface names is a confusion for everyone with non-PHP development experience. There's not a modern OO platform that defines an interface named 'IDispatch' and later allows it to be referenced as 'idispatch' or 'iDispatch'. And PHP is becoming more OO with every major release. Overall, full case-sensitivity seems to be a natural step in PHP's evolution. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 4/20/2012 9:48 PM, C.Koy wrote: Java, C#, Python, Ruby... are all case-sensitive. This is not a feature to be (mis-)used so that one can have a function named myfunc() and MyFunc() in the same code base. Case-insensitive class/function/interface names is a confusion for everyone with non-PHP development experience. There's not a modern OO platform that defines an interface named 'IDispatch' and later allows it to be referenced as 'idispatch' or 'iDispatch'. And PHP is becoming more OO with every major release. Overall, full case-sensitivity seems to be a natural step in PHP's evolution. Let me add this: case-insensitivity is a burden for tool developers. For example, any ctags-based editor/IDE out there won't find the definition of myfunc() when you request Goto tag's definition if it's defined as MyFunc(). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
Hi there, Out of curiosity, how would one migrate a codebase for full case sensitivity in PHP? They would need to rewrite their calls of core functions, plus PECL functions. Those are easy enough to spot, but there are also custom extensions. True, one could maybe parse the .h files to get the functions, classes, interfaces etc. as long as there are .h files or similar, and rewrite everything based on that. However, there are also userland functions, classes and other identifiers that could be defined anywhere, from files on disk to an encrypted database somewhere. Plus, as Matthew pointed out, identifiers are not always fully written in the code: they can be concatenated or aliased, and these calls would need to be rewritten too (and good luck finding them all). I am sure I have not listed here all the challenges in migrating for this new functionality, but I hope it will be enough that we do _not_ get case sensitivity for functions/classes/interfaces/etc. in PHP. The cost truly outweights the benefits. I can understand why bug #18556 should be fixed, but I don't understand why the solution should be to make PHP a fully case sensitive language. @C.Koy: until now, tools have been able to cope with PHP's case insensitivity just fine. I have no idea how difficult it is to do, but obviously they can do it. And anyway, I use tools _because_ they do some of the work for me, so that's just a tribute to their usefullness, isn't it? Regarding other languages, it has been stated before on this list that PHP is its own language. Regards, -- Guillaume Rossolini
Re: [PHP-DEV] Complete case-sensitivity in PHP
On 04/20/2012 08:48 PM, C.Koy wrote: On 4/20/2012 8:57 PM, Kris Craig wrote: Turkish localization notwithstanding (I confess that I know absolutely * nothing* about that lol), one possible use-case could be if you're including an external library/framework that contains a function with the same name but different case. I'm not sure how likely that is, mind you, but I can see that as one potential benefit. Either way, I guess my point is that the arguments for/against this seem to parallel the arguments for Windows-style fso case-insensitivity vs. Unix-style fso case-sensitivity. Java, C#, Python, Ruby... are all case-sensitive. This is not a feature to be (mis-)used so that one can have a function named myfunc() and MyFunc() in the same code base. Case-insensitive class/function/interface names is a confusion for everyone with non-PHP development experience. There's not a modern OO platform that defines an interface named 'IDispatch' and later allows it to be referenced as 'idispatch' or 'iDispatch'. And PHP is becoming more OO with every major release. Overall, full case-sensitivity seems to be a natural step in PHP's evolution. I also have the feeling that cleaner code with consistent case would be a benefit. While I admit we can't change that from one day to the other (as we couldn't with other changes) I think we might possibly add a special kind of deprecation where the non-matching case would still work but (if you activate those deprecation-warnings) would trigger warnings so you can clean up your code. Various projects that I work on take explicit care of the case when auto-creating classnames etc. - not because they must but because they want to be consistent. And that's the thing I like about it. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On Sat, 2012-04-21 at 01:16 +0200, Stefan Neufeind wrote: I think we might possibly add a special kind of deprecation where the non-matching case would still work but (if you activate those deprecation-warnings) would trigger warnings so you can clean up your code. yay - two lookups instead of one ;-) and what would you do in this strange, but possible case: The functions Foo() and FOO() exist but the user calls foo()? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Complete case-sensitivity in PHP
On Fri, Apr 20, 2012 at 3:20 AM, C.Koy can5...@gmail.com wrote: 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. What about instead creating a special-purpose Zend function to normalize class names (zend_normalize_class_name, or zend_classname_tolower)? This function would examine the current locale and, if it's a problematic one, convert the string to lower case on its own (calling zend_tolower on non-problematic characters). Alternatively, zend_normalize_class_name could switch LC_CTYPE to an appropriate locale (e.g. UTF-8; the locale could be determined at compile time), call zend_str_tolower_copy, then switch back before returning. Then, any appropriate function (e.g. zend_resolve_class_name, zend_lookup_class_ex, class_exists, class_alias) would call zend_normalize_class_name instead of zend_str_tolower_copy/ zend_str_tolower_dup. The two problems with this approach are 1) additional time-cost. However, if done right, this should have little impact. 2) break class names using words in the locale-language. For example, a class named IzgaraGörünümü would be converted to izgaragörünümü, rather than ızgaragörünümü. However, this impact should be less than that caused by the current bug. Does this bug pop-up for locales other than Turkish, Azerbaijani and Kurdish ?
