On 4/22/2012 11:32 PM, Galen Wright-Watson wrote:
2012/4/22 C.Koy
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 i
Hi,
2012/4/23 Galen Wright-Watson :
>> 2. Absent bug #18556, case-sensitive PHP has merits as I stated in other
>> post and several people voiced opinions in favor. Case-sensitive PHP is
>> worth considering.
>>
>> It is, but it's also a major BC break, hence perhaps better suited for
> PHP6. Case
2012/4/22 C.Koy
> On 4/21/2012 4:37 AM, Galen Wright-Watson wrote:
>
>> 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,
On 4/21/2012 4:37 AM, Galen Wright-Watson wrote:
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
Hi,
I'm just curious if anyone took benchmark.
PoC would be simple enough.
Some figures are needed for decision.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 04/21/2012 01:56 AM, Johannes � wrote:
> 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
On 12-04-20 07:56 PM, Johannes Schlüter wrote:
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 c
On Fri, Apr 20, 2012 at 3:20 AM, C.Koy 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 creati
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 inst
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 wit
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 fun
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
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 sur
> 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, b
On 2012-04-20, Kris Craig wrote:
> On Fri, Apr 20, 2012 at 8:44 AM, Sherif Ramadan
> 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.
On Fri, Apr 20, 2012 at 8:44 AM, Sherif Ramadan 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/f
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 usi
> 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
> insensiti
On Fri, Apr 20, 2012 at 9:01 AM, Sherif Ramadan wrote:
> >>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\x8
>>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 wh
Because you can write a function name, say, in Cyrilic and it will just
work.
20 апреля 2012 г. 16:47 пользователь Nikita Popov написал:
> On Fri, Apr 20, 2012 at 12:20 PM, C.Koy wrote:
> > Hi,
> >
> > This post is about bug #18556 (https://bugs.php.net/bug.php?id=18556)
> which
> > is a decade
On Fri, Apr 20, 2012 at 12:20 PM, C.Koy 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
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
23 matches
Mail list logo
