The easiest thing would be just to default unicode_semantics to On
internally and hide it from users. Don't remove all the UG(unicode)
checks yet, because we can test migration/compatibility with those in place.
-Andrei
Derick Rethans wrote:
On Wed, 7 May 2008, Andi Gutmans wrote:
Yep, we sa
See below:
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 08, 2008 12:23 AM
> To: Andi Gutmans
> Cc: Andrei Zmievski; PHP Developers Mailing List
> Subject: RE: [PHP-DEV] Removal of unicode_semantics
>
>
> Scott
On Wed, 7 May 2008, Andi Gutmans wrote:
> Yep, we said that we'd remove the switch. Then we'd see how
> compatibility fairs and if we discover the upgrade path is too painful
> we'd consider making "" be binary string and require u"" for Unicode
> strings. But this was TBD depending on people's
On Thu, May 8, 2008 at 7:33 AM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> So for now we should remove the switch. We can do this if needed.
Who is "we" in this context? Zend?
Scott is already working on the removal but I'll bet he would really
appreciate help with it.
-Hannes
--
PHP Internals
ethans
> Cc: Tomas Kuliavas; internals@lists.php.net
> Subject: Re: [PHP-DEV] Removal of unicode_semantics
>
> As far as I remember, the latest point was to remove the
> unicode_semantics switch and presume that its value is always On. At
> the
> same time we said that binary strin
Precisely.
Stefan Walk wrote:
Lester Caine schrieb:
That sounds like just the sort of edge case that Derick is suggesting
needs logging for fixing up. unicode_semantics=on is just another
bodge to to make it happen rather than a solution. I think I
understand your description, and to my eyes
Tomas Kuliavas wrote:
If I remain silent, others will have arguments that "everybody agrees on
removal of unicode_semantics".
I write and maintain charset decoding and encoding functions.
unicode_semantics breaks every mapping table and other functions that
operate with binary 8bit strings.
Ju
On 07.05.2008, at 18:35, Andrei Zmievski wrote:
As far as I remember, the latest point was to remove the
unicode_semantics switch and presume that its value is always On. At
the same time we said that binary strings should probably be the
default string type (which I don't agree with), and
As far as I remember, the latest point was to remove the
unicode_semantics switch and presume that its value is always On. At the
same time we said that binary strings should probably be the default
string type (which I don't agree with), and that we need to have a test
suite to see what exactl
+1 for removal.
"Scott MacVicar" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi everyone,
>
> We've discussed this a few times in the past and it's time to make a
> final decision about its removal.
>
> I think most people have agreed that this is the way forward but no one
>
Arvids Godjuks wrote:
> Well, at least in my country i haven't saw any normal programmer not using
> unicode :)
I guess that was meant to be an ironic comment but I think we should
improve the signal-to-noise ration on internals again.
- Chris
--
PHP Internals - PHP Runtime Development Mailin
Well, at least in my country i haven't saw any normal programmer not using
unicode :)
2008/5/5 Christian Schneider <[EMAIL PROTECTED]>:
> Arvids Godjuks wrote:
> > Most normal developers are for years with utf-8 for now and even
> wouldn't
> > notice it.
>
> Sorry to destroy your pipe dream but t
Arvids Godjuks wrote:
> Most normal developers are for years with utf-8 for now and even wouldn't
> notice it.
Sorry to destroy your pipe dream but that's just not true.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Just use Unicode and don't even think about backward compability, because
thouse who need it most probably still are with PHP4 and MySQL 3.x
Most normal developers are for years with utf-8 for now and even wouldn't
notice it.
So +1 for pure Unicode. No switches. Lame hosting companies 100% will me
Am 05.05.2008 um 09:51 schrieb Antony Dovgal:
On 04.05.2008 20:34, Tomas Kuliavas wrote:
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a
Derick Rethans wrote:
On Mon, 5 May 2008, Lester Caine wrote:
So from *MY* point of view unicode_semantics=on is creating a THIRD
case to have to manage? PLEASE can someone take charge and at least
get PHP6 moving forward to a stable alpha so that we have something
users can be happy to test
On 05.05.2008 12:44, Tomas Kuliavas wrote:
PHP4, PHP5 and PHP6 unicode_semantics = off work same way.
No, they do not work in the same way.
I.e. we were trying to make PHP5 work in the same way PHP4 did as much as
we could, but that's not always possible.
In my case they do.
This means your
>> PHP4, PHP5 and PHP6 unicode_semantics = off work same way.
>
> No, they do not work in the same way.
> I.e. we were trying to make PHP5 work in the same way PHP4 did as much as
> we could, but that's not always possible.
In my case they do.
--
Tomas
--
PHP Internals - PHP Runtime Developme
On Mon, 5 May 2008, Lester Caine wrote:
> So from *MY* point of view unicode_semantics=on is creating a THIRD
> case to have to manage? PLEASE can someone take charge and at least
> get PHP6 moving forward to a stable alpha so that we have something
> users can be happy to test against!
I thin
On 05.05.2008 12:16, Tomas Kuliavas wrote:
PHP4, PHP5 and PHP6 unicode_semantics = off work same way.
No, they do not work in the same way.
I.e. we were trying to make PHP5 work in the same way PHP4 did as much as
we could, but that's not always possible.
Same for PHP6 - there will be some d
> Lester Caine schrieb:
>> That sounds like just the sort of edge case that Derick is suggesting
>> needs logging for fixing up. unicode_semantics=on is just another bodge
>> to to make it happen rather than a solution. I think I understand your
>> description, and to my eyes it looks like a unicod
Lester Caine schrieb:
That sounds like just the sort of edge case that Derick is suggesting
needs logging for fixing up. unicode_semantics=on is just another bodge
to to make it happen rather than a solution. I think I understand your
description, and to my eyes it looks like a unicode bug that
>
>
> My biggest concern is the 2 code bases that need to be maintained by the
> PHP developers, you need to have two branches for handling unicode and
> native strings.
> To sum it up, unicode_semantics is in the exact same vain as
> ze1_compatability and it was a complete failure.
Totally agr
On 04.05.2008 20:34, Tomas Kuliavas wrote:
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a student working on unicode
conversion for the G
Tomas Kuliavas wrote:
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a student working on unicode
conversion for the Google Summer of Code
>> > We've discussed this a few times in the past and it's time to make a
>> > final decision about its removal.
>> >
>> > I think most people have agreed that this is the way forward but no
>> > one has produced a patch. I have a student working on unicode
>> > conversion for the Google Summer of
Hey Scott
As the most others already have posted, then from the php developers point
it would be stupid to maintain two versions of the same function unless you
wrap it all into a function that does it by itself.
And yes zend.ze1_compatibility_mode was a major failure.
+1 for removal
Kalle
--
Tomas Kuliavas wrote:
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a student working on unicode
conversion for the Google Summer of Code
On Sun, May 4, 2008 at 8:34 PM, Tomas Kuliavas
<[EMAIL PROTECTED]> wrote:
> > We've discussed this a few times in the past and it's time to make a
> > final decision about its removal.
> >
> > I think most people have agreed that this is the way forward but no
> > one has produced a patch. I ha
Tomas Kuliavas wrote:
We've discussed this a few times in the past and it's time to make a
final decision about its removal.
I think most people have agreed that this is the way forward but no
one has produced a patch. I have a student working on unicode
conversion for the Google Summer of Code
On Sun, 4 May 2008, Tomas Kuliavas wrote:
> > We've discussed this a few times in the past and it's time to make a
> > final decision about its removal.
> >
> > I think most people have agreed that this is the way forward but no
> > one has produced a patch. I have a student working on unicode
> >
> We've discussed this a few times in the past and it's time to make a
> final decision about its removal.
>
> I think most people have agreed that this is the way forward but no
> one has produced a patch. I have a student working on unicode
> conversion for the Google Summer of Code and this woul
32 matches
Mail list logo