Hi!
> You had less complex patch posted on #35050 bug report for the last four
> years.
That patch, unfortunately, is not correct since it assumes every
function using tolower wants ASCII tolower. This makes, for example,
substr_compare() ignore locale, and probably a bunch of other functions.
Wh
2012.07.11 23:07, Pierre Joye rašė:
> hi,
>
> On Wed, Jul 11, 2012 at 10:01 PM, Stas Malyshev
> wrote:
>> Hi!
>>
>>> I'd to go with master only with this patch, not like it is a huge
>>> issue either (% wised I mean).
>>
>> It's a huge issue for people using these locales (PHP is unusable for
>>
Hi!
> One thing to keep in mind when doing this is to think about consistency.
> Right there's quite a distinction. Things either take an array or a
> Traversable object. We should think about not creating a mess when some
> functions, especially ones called array_foo() allow Traversable while
> o
Hi!
> To add my $0.02, it'd be nice to work in a zend_parse_parameters() type for
> this. Keep extension code clean and ensures any temporary iterators get
> destructed.
Definitely, that'd be a great benefit. Just return zend_iterator * which
you can use to get current/next zvals and converting
Hello all,
Since the discussion has died down around the concept, I have updated the
RFC and moved it into Proposed (under discussion) status.
I have updated the RFC to include a section on discussion points containing
points that I know were raised but I felt were not closed (there was some
deba
On Wed, 2012-07-11 at 20:39 -0400, Anthony Ferrara wrote:
> Johannes,
>
> One thing to keep in mind when doing this is to think about consistency.
> >
>
> I think that's a huge point not to be taken lightly. For that reason, I
> think that this API should not be used for any of the array_* functi
On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara wrote:
> Johannes,
>
> One thing to keep in mind when doing this is to think about consistency.
> >
>
> I think that's a huge point not to be taken lightly. For that reason, I
> think that this API should not be used for any of the array_* functions
Johannes,
One thing to keep in mind when doing this is to think about consistency.
>
I think that's a huge point not to be taken lightly. For that reason, I
think that this API should not be used for any of the array_* functions.
Meaning that array_sum(), etc should all take arrays only.
Then, o
On Thu, 2012-07-12 at 01:49 +0200, Johannes Schlüter wrote:
> Just picking some random example:
>
> * array_map() - This can be implemented using that infrastructure.
> (While some might think about returning an Traversable object if
> a Traversable object got put in, maybe a
On Thu, 2012-07-12 at 00:17 +0200, Nikita Popov wrote:
> Hi internals!
>
> Currently PHP does not have an internal iteration API that supports
> both arrays and Traversable objects.
Yes. in fact doing that is long overdue.
> Because of that it is currently
> not really possible to write functio
Love the idea. +1
On Wed, Jul 11, 2012 at 3:17 PM, Nikita Popov wrote:
> Hi internals!
>
> Currently PHP does not have an internal iteration API that supports
> both arrays and Traversable objects. Because of that it is currently
> not really possible to write functions (or language features) th
Hi internals!
Currently PHP does not have an internal iteration API that supports
both arrays and Traversable objects. Because of that it is currently
not really possible to write functions (or language features) that
work on arbitrary traversables. That's probably also the reason why
function lik
hi Stas!
On Wed, Jul 11, 2012 at 10:45 PM, Stas Malyshev wrote:
> Hi!
>
>> That adds way too much risks, for little to no gain (sorry for the few
>> people suffering from this bug).
>
> Which exactly risks? So far only description of risks was from Hannes,
> and all the function he mentioned do n
hi,
On Wed, Jul 11, 2012 at 10:36 PM, Gustavo Lopes wrote:
> Em Wed, 11 Jul 2012 22:17:42 +0200, Stas Malyshev
> escreveu:
>
>
>> And we regularly fix bugs in such functions in stable versions.
>>
>>> If it is not good enough for 5.3, it is not good enough for 5.4.
>>
>>
>> Sorry, I can't accept
Hi!
> You're changing the Zend API. You introduce new public functions. This
> means an extension that uses the new symbols will be compatible with PHP
> 5.4.6, but not before. When this happens, it's very annoying (like the
> PHP_FE_END in 5.3, though that only affected source compatibility
Hi!
> That adds way too much risks, for little to no gain (sorry for the few
> people suffering from this bug).
Which exactly risks? So far only description of risks was from Hannes,
and all the function he mentioned do not call any of the functions being
changed.
--
Stanislav Malyshev, Software
Em Wed, 11 Jul 2012 22:17:42 +0200, Stas Malyshev
escreveu:
And we regularly fix bugs in such functions in stable versions.
If it is not good enough for 5.3, it is not good enough for 5.4.
Sorry, I can't accept this argument. There were numerous things that are
in 5.4 but not in 5.3.
I
Hi!
> Right, just like some functions are huge issues for the few people using them.
And we regularly fix bugs in such functions in stable versions.
> If it is not good enough for 5.3, it is not good enough for 5.4.
Sorry, I can't accept this argument. There were numerous things that are
in 5.4
hi,
On Wed, Jul 11, 2012 at 10:01 PM, Stas Malyshev wrote:
> Hi!
>
>> I'd to go with master only with this patch, not like it is a huge
>> issue either (% wised I mean).
>
> It's a huge issue for people using these locales (PHP is unusable for
> them, as I understand), but how many use those I do
Hi!
> I'd to go with master only with this patch, not like it is a huge
> issue either (% wised I mean).
It's a huge issue for people using these locales (PHP is unusable for
them, as I understand), but how many use those I don't know.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://w
Hi!
> It is a thing that can have really weird cascading affects.
>
> Everything from strcmp() to == and sort() could start behaving differently.
Why? Neither of them is case insensitive, why would they start behaving
differently? And sort has nothing to do with it at all, lowercasing does
not a
On Wed, Jul 11, 2012 at 7:10 PM, Stas Malyshev wrote:
> Hi!
>
>> Hang on. Are you really going to push this into 5.4?
>
> Do you have some comments?
It is a thing that can have really weird cascading affects.
Everything from strcmp() to == and sort() could start behaving differently.
The test ca
hi Stas,
On Wed, Jul 11, 2012 at 8:08 PM, Stas Malyshev wrote:
> Hi!
>
>> Even if the concerns from this thread can be cleared I don't think we
>> should change the core language in a version like 5.3. 5.3 users who are
>> hit by this have their work-around (I assume), others have a good reason
>
Hi!
> Hang on. Are you really going to push this into 5.4?
Do you have some comments?
--
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.ph
On Wed, Jul 11, 2012 at 7:08 PM, Stas Malyshev wrote:
> Hi!
>
>> Even if the concerns from this thread can be cleared I don't think we
>> should change the core language in a version like 5.3. 5.3 users who are
>> hit by this have their work-around (I assume), others have a good reason
>> to use a
Hi!
> Even if the concerns from this thread can be cleared I don't think we
> should change the core language in a version like 5.3. 5.3 users who are
> hit by this have their work-around (I assume), others have a good reason
> to use a more modern PHP.
OK, I'll leave 5.3 alone then.
It shouldn't
On Tue, 2012-07-10 at 22:40 -0700, Stas Malyshev wrote:
> Johannes, is it ok to put this fix into 5.3 too?
Even if the concerns from this thread can be cleared I don't think we
should change the core language in a version like 5.3. 5.3 users who are
hit by this have their work-around (I assume), o
Hi!
> In some locales weird things start within ASCII range and PHP was hit by
> them multiple times.
And that's exactly the reason for this patch.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development M
2012.07.11 19:17, Stas Malyshev rašė:
> Hi!
>
>> I don't think ASCII-only lowercasing is compatible to the allowed PHP
>> identifier characters used by class names and what else.
>
> Right now we use tolower() which is system-dependent, locale-dependent
> and doesn't really work with any characte
Hi!
> I don't think ASCII-only lowercasing is compatible to the allowed PHP
> identifier characters used by class names and what else.
Right now we use tolower() which is system-dependent, locale-dependent
and doesn't really work with any character that is not 8-bit since it
uses per-character lo
Hi!
> I would make the Zend engine use the ROOT Locale for PHP's language parsing
> (in Java it's called Locale.ROOT, in C it’s the Locale named ""), so its
> invariant to local settings but works correct for all of Unicode. In theory,
Yeah, right, in theory we need full unicode support. In pract
Hi!
> With this patch, will it still be possible to use foreign class names
> correctly? Like writing them in Russian and expecting the
> case-insensitivity to work correct?
Not really. Did it ever work properly?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)4
Sorry, typo:
> I don't think ASCII-only lowercasing is in-compatible to the allowed PHP
> identifier characters used by class names and what else.
I don't think ASCII-only lowercasing is compatible to the allowed PHP
identifier characters used by class names and what else.
Uwe
> -
> Uwe Schi
Hi Nikita,
That was my first problem with the code, too!
I would make the Zend engine use the ROOT Locale for PHP's language parsing
(in Java it's called Locale.ROOT, in C its the Locale named ""), so its
invariant to local settings but works correct for all of Unicode. In theory,
this "case ins
On Wed, Jul 11, 2012 at 7:40 AM, Stas Malyshev wrote:
> Hi!
>
> I've prepared a fix for bug #18556 - see
> https://github.com/php/php-src/pull/126
> A slight complication there is that for internal operations we probably
> want locale-independent lowercasing, while for regular string operations
>
35 matches
Mail list logo
