On Tue, August 21, 2007 1:22 am, Lukas Kahwe Smith wrote:
Andi Gutmans wrote:
Before we continue this discussion I think there are a couple of
things
which would be useful data points:
a) What is the performance difference between an implicit Unicode
app
and non-Unicode. If we have 3-4 apps
On Tue, August 21, 2007 5:21 pm, Stanislav Malyshev wrote:
So if you don't deal with them, you'd just say we don't run on PHP
6.
Is it better than saying we run on PHP 6 only with that specific
setting?
Yes, it is better, imho.
--
Some people have a gift link here.
Know what I want?
I want
Why can't the unicode switch be turn on/off by the application when needed?
Perhaps have an on/off/auto setting where auto meaning it'll remain off
unless the application explicitly asks for it.
On 8/21/07, Larry Garfield [EMAIL PROTECTED] wrote:
Andi,
Is there a guide somewhere for those who
Hi Andi,
Am 21.08.2007 um 21:32 schrieb Andi Gutmans:
If there's an overwhelming support for removing the switch then I
guess
that's where it is. I still think it's a mistake and we are risking a
big split in the user base going forward but time will tell. Long term
PHP may not recover from
Why can't the unicode switch be turn on/off by the application when needed?
Perhaps have an on/off/auto setting where auto meaning it'll remain off
unless the application explicitly asks for it.
Because it's very hard to implement since we'd have to keep 2 copies of
all symbol tables.
--
Well that's the problem. We have put months (if not more) of work into
PHP 6 but most people who are complaining aren't willing to take a stab
at actually help figuring this out.
No matter what we end up doing, the worst is if we make an arbitrary
decision because no one had time to get the right
On Mon, 20 Aug 2007, Andi Gutmans wrote:
No I'm absolutely not OK with removing this switch and as we currently
did most of the implementation for it and are maintaining it I see no
reason to remove it. 95% of our users couldn't care less about native
Unicode support except for the
Andi Gutmans wrote:
Before we continue this discussion I think there are a couple of things
which would be useful data points:
a) What is the performance difference between an implicit Unicode app
and non-Unicode. If we have 3-4 apps ported over to Unicode_semantics=on
Honestly I do not see
I don't think it's a matter of agreeing but rather we can try and figure out
how to get out of this stale mate. This includes going down the path I
suggested which includes doing some more homework to figure this out. I am
keeping an open mind and am willing to be convinced but I feel there's
On Mon, 20 Aug 2007, Stanislav Malyshev wrote:
And if Andrei, who is mostly behind (afaict) the whole thing, says he's okay
with getting rid of the totally useless option then in my eyes that's the
death sentence for the option.
In your eyes - fine. But besides your personal eyes, there
On Mon, 20 Aug 2007, Andi Gutmans wrote:
On Tue, 21 Aug 2007, Derick Rethans wrote:
On Mon, 20 Aug 2007, Andi Gutmans wrote:
No I'm absolutely not OK with removing this switch and as we currently
did most of the implementation for it and are maintaining it I see no
reason to
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Monday, August 20, 2007 11:40 PM
To: Andi Gutmans
Cc: Andrei Zmievski; Lukas Kahwe Smith; Antony Dovgal; Rasmus Lerdorf;
PHP Developers Mailing List
Subject: RE: [PHP-DEV] What is the use of unicode.semantics in
Andi Gutmans wrote:
Anyway, as I suggested, let's do more homework. We started and it wasn't a
pretty sight. But still lots to do. There seem to be enough passionate people
on this list to actually port 3-4 apps over and give us some more input on the
answers we really need.
I have kept out
Andi Gutmans wrote:
Maybe you guys can try with ezComponents?
So whats your target with this BC flag .. make it possible to have
PHP4-PHP6 (unicode off) apps?
Keep in mind that the camp that is suggesting to remove the unicode flag
is at the same time committing to back porting more
So what happened to the Open in OpenSource or is PHP now something
else now?
btw. 95% of Zend users propably don't need unicode but there are a lot
more people out there who can't really use PHP right now since it
doesn't have full unicode support. The percents pulled out of sleeve
would be
On Tue, 2007-08-21 at 08:18 +0200, Derick Rethans wrote:
On Mon, 20 Aug 2007, Andi Gutmans wrote:
Anyway, don't want to reignite the thread here. I will take it offline
to discuss with the people who have been involved in this project and
discuss further. The mailing list here isn't exactly
On 21/08/07, Jani Taskinen [EMAIL PROTECTED] wrote:
On Tue, 2007-08-21 at 08:18 +0200, Derick Rethans wrote:
On Mon, 20 Aug 2007, Andi Gutmans wrote:
Anyway, don't want to reignite the thread here. I will take it offline
to discuss with the people who have been involved in this project
So what happened to the Open in OpenSource or is PHP now something
else now?
btw. 95% of Zend users propably don't need unicode but there are a lot
more people out there who can't really use PHP right now since it
doesn't have full unicode support. The percents pulled out of sleeve
would be
On Tue, 2007-08-21 at 08:31 +0100, Lester Caine wrote:
How much work do people think *IS* involved in porting a large application
over to PHP6? Reading between the lines it looks like we are talking file
conversion to UTF-16 + what? What is currently a show stopper to simply
running a PHP5
Uhm, what makes you think we don't have asian users? I also don't recall
suggesting that we should not have Unicode support.
Don't forget how much we invested in implementing this in the engine. It
was far from trivial...
Andi
-Original Message-
From: Jani Taskinen [mailto:[EMAIL
Hi,
Ok, so I think its becoming clear that BC is not the main issue we will
be addressing with the unicode switch. I know Zeev's mantra that BC is
not binary, but from the people that have posted feedback on the topic
from actual experience it seems that making code work on PHP5 (and even
-Original Message-
From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 21, 2007 1:30 AM
To: Andi Gutmans
Cc: Derick Rethans; Andrei Zmievski; Antony Dovgal; Rasmus Lerdorf; PHP
Developers Mailing List
Subject: Re: [PHP-DEV] What is the use of unicode.semantics
Hi everybody,
I first want to personally thank everybody who have voiced their opinions on
this subject as it shows how much concern you all have for PHP.
To give a bit of background, I am one of the PHP Google Summer of Code
students and part of my project was to port/create a PHP 6
Nicolas Bérard-Nault wrote:
I have one specific example of where this can be a HUGE headache. Let's
say you have some serialized configuration files, saved with
unicode.semantics = 1, containing a single configuration array. Now, for
some reason, the administrator decides to turn
If there's an overwhelming support for removing the switch then I guess
that's where it is. I still think it's a mistake and we are risking a
big split in the user base going forward but time will tell. Long term
PHP may not recover from that split unless we truly manage to help the
most popular
portable as possible. To create a portable application for PHP 6, you have
to consider the two different unicode.semantics scenarios AND the
possibility that the switch, for some reason, might be turned on or off at
any time in the future. Even if you don't care about Unicode and/or have
never
Andi,
Is there a guide somewhere for those who are PHP developers, not C developers,
who would want to try existing code under PHP 6 but don't know all the ins
and outs of the new unicode system? It sounds like there's 3-4 unicode
switches in php.ini, but maybe I'm missing some and I'm sure I
On 7/6/07, Stefan Priebsch [EMAIL PROTECTED] wrote:
IMHO backporting a lot of features to PHP4 is a major reasons for the
slow PHP5 adoption. Basically, it seems that everybody who is not using
OOP feels that PHP4 is fine for them.
I'd say committing to backporting stuff from PHP6 to PHP5
Nothing is happening, as far as I can tell. We are at an impasse,
basically. Personally, I am fine with removing the damn switch and
going forward with PHP 6 as Unicode-only. God knows it will rid us of
at least one headache - having to discuss it anymore.
-Andrei
http://10fathoms.org/vu -
FINALLY we're getting somewhere. Now where to start removing all the crap that
was necessary for the non-unicode mode? (I'd say the tests..)
--Jani
Andrei Zmievski kirjoitti:
Nothing is happening, as far as I can tell. We are at an impasse,
basically. Personally, I am fine with removing the
FINALLY we're getting somewhere. Now where to start removing all the
I don't see how we are getting somewhere - as before, there are people
for removing it and against removing it. Nothing changed, as far as I
see. Why suddenly should we start removing anything?
--
Stanislav Malyshev, Zend
Stanislav Malyshev kirjoitti:
FINALLY we're getting somewhere. Now where to start removing all the
I don't see how we are getting somewhere - as before, there are people
for removing it and against removing it. Nothing changed, as far as I
see. Why suddenly should we start removing anything?
On 20.08.2007 20:14, David Coallier wrote:
Time to put gas on the fire.
Is this flag going to be removed or what? What is happening here in
the background that we are not seeing ? :)
Nothing.
It's stuck.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To
FINALLY we're getting somewhere. Now where to start removing all the
I don't see how we are getting somewhere - as before, there are people
for removing it and against removing it. Nothing changed, as far as I
see. Why suddenly should we start removing anything?
For some reason only totally
Because we can't stay in the stasis forever? What concrete steps do
you propose to change the current situation?
-Andrei
http://10fathoms.org/vu - daily photoblog
On Aug 20, 2007, at 12:54 PM, Stanislav Malyshev wrote:
FINALLY we're getting somewhere. Now where to start removing all the
I
For some reason only totally opposing people have Z in their email
address domain..
Even if it were true (which it isn't) - so what?
And if Andrei, who is mostly behind (afaict) the whole thing, says he's
okay with getting rid of the totally useless option then in my eyes
that's the death
On 8/20/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
In your eyes - fine. But besides your personal eyes, there is also such
thing as consensus, and it wasn't achieved.
Excuse me but it is achieved, you only don't see it, or refuse to see it.
--Pierre
--
PHP Internals - PHP Runtime
No I'm absolutely not OK with removing this switch and as we currently
did most of the implementation for it and are maintaining it I see no
reason to remove it. 95% of our users couldn't care less about native
Unicode support except for the performance hit they'd take due to the
slower functions
Before we continue this discussion I think there are a couple of things
which would be useful data points:
a) What is the performance difference between an implicit Unicode app
and non-Unicode. If we have 3-4 apps ported over to Unicode_semantics=on
with only true binary strings cast to binay and
On Sat, July 14, 2007 9:00 am, Rasmus Lerdorf wrote:
Richard Lynch wrote:
$a = ãÆžãÆâ¹Ã£Æ¥ãâ¢ãÆ«;
echo $a[1];
Whoa.
That was weird...
Right, your mail client doesn't handle Unicode correctly. You might
want to do something about that.
Or not, since I don't have any
On Wed, July 11, 2007 9:14 pm, Rasmus Lerdorf wrote:
Richard, you are rather confused on this Unicode stuff.
I'm 100% certain we can all agree on that point. :-)
The fact that
PHP and ICU uses UTF-16 internally has absolutely nothing to do with
what is exposed at the scripting level.
But
But if you write:
$a = マニュアル;
echo $a[1];
Whoa.
That was weird...
It was just a bunch of question marks when I read it, and now it's a
bunch of symbols (variants on afz mostly) in my reply...
Your browser or operating system does not support Japanese symbols and
translation selected in
That sounds good in my ears.
Software that relys on old non-unicode behaviour must be written in a
way two handle non-unicode and Unicode behaviour in two different ways.
But for example a rewritten Squirrelmail that runs exlusively on PHP6
would be a good thing.
So you could write on your
On Wed, 11 Jul 2007, Richard Quadling wrote:
On 11/07/07, Evert | Rooftop [EMAIL PROTECTED] wrote:
Larry Garfield wrote:
Top 10 by what metric? If I had to guess based on market share, I'd say
(unordered):
Drupal
Squirrelmail
WordPress
phpMyAdmin
MediaWiki
Joomla
On Wed, 11 Jul 2007 20:23:20 -0500 (CDT), Richard Lynch [EMAIL PROTECTED]
wrote:
Remember that old series of jokes about how C is a language that lets
you shoot your foot off?
runkit lets you design a gun so you can use one foot to shoot the other.
LOL!
Yes, I've been looking at it as
On Wed, 11 Jul 2007 20:27:21 -0500 (CDT), Richard Lynch [EMAIL PROTECTED]
wrote:
On Wed, July 11, 2007 3:11 am, Richard Quadling wrote:
On 11/07/07, Evert | Rooftop [EMAIL PROTECTED] wrote:
Larry Garfield wrote:
Top 10 by what metric? If I had to guess based on market share,
I'd say
Richard Lynch wrote:
On Wed, July 11, 2007 3:11 am, Richard Quadling wrote:
On 11/07/07, Evert | Rooftop [EMAIL PROTECTED] wrote:
Larry Garfield wrote:
Top 10 by what metric? If I had to guess based on market share,
I'd say
(unordered):
Drupal
Squirrelmail
WordPress
phpMyAdmin
MediaWiki
Larry Garfield schrieb:
On Tuesday 10 July 2007, Evert | Rooftop wrote:
Andi Gutmans wrote:
I think the sooner the better as it's valuable information for the dev
team.
It'd probably be a good idea to have a Wiki where we can document issues
that/common use-cases which are encountered.
From our perspective, you've gone and changed a fundamental data
structure out from under us, in a non-backwards-compatible way, and
broken a whole bunch of working code, for a feature we don't use, and
can't turn off [*]
Supporting unicode requires such change. It is a big deal - Unicode does
AFAIK, UTF-8 is backward compatible with ASCII. UTF-16 is not. That's why
Well, with 7-bit ASCII - yes. With 8-bit extended ASCII, whatever that
means - not exactly. You can have 8-bit strings that aren't valid UTF-8
and can't be translated to UTF-8 without specifying the encoding
Am 11.07.2007 um 07:20 schrieb Evert|Rooftop:
Top 10 by what metric? If I had to guess based on market share,
I'd say (unordered):
Drupal
Squirrelmail
WordPress
phpMyAdmin
MediaWiki
Joomla
PHPBB
hey, and what about TYPO3? ;-)
Honestly, I've tried the current version of TYPO3 (4.x) with
On 11/07/07, Evert | Rooftop [EMAIL PROTECTED] wrote:
Larry Garfield wrote:
Top 10 by what metric? If I had to guess based on market share, I'd say
(unordered):
Drupal
Squirrelmail
WordPress
phpMyAdmin
MediaWiki
Joomla
PHPBB
That will keep me busy =)
Evert
Would it also be
On 11.07.2007, at 07:15, Larry Garfield wrote:
On Tuesday 10 July 2007, Evert | Rooftop wrote:
Andi Gutmans wrote:
I think the sooner the better as it's valuable information for
the dev
team.
It'd probably be a good idea to have a Wiki where we can document
issues
that/common use-cases
On 11.07.2007, at 00:02, Andi Gutmans wrote:
I think the sooner the better as it's valuable information for the dev
team.
It'd probably be a good idea to have a Wiki where we can document
issues
that/common use-cases which are encountered.
Maybe we should have a Wiki on one of the php.net
On Wed, 2007-07-11 at 10:21 +0200, Lukas Kahwe Smith wrote:
we tried to get most of the top php OSS projects into the primary
testers group:
http://oss.backendmedia.com/PhP4yz
http://oss.backendmedia.com/PhP5yz
http://oss.backendmedia.com/PhP6yz
Emphasis on word tried ? :D
Is there some
On Wed, 11 Jul 2007 01:20:44 -0400, Evert | Rooftop [EMAIL PROTECTED] wrote:
Larry Garfield wrote:
Top 10 by what metric? If I had to guess based on market share, I'd say
(unordered):
Drupal
Squirrelmail
WordPress
phpMyAdmin
MediaWiki
Joomla
PHPBB
That will keep me busy =)
On Wed, 2007-07-11 at 10:24 +0200, Lukas Kahwe Smith wrote:
this and IIRC the only opposition has always been Rasmus that insists
that things like this should be in CVS (yes I know we have a todo
file in CVS). But it seems to me like most internals developers have
showed their preference
On Mon, July 9, 2007 3:06 am, Stanislav Malyshev wrote:
But now \xF0 isn't going to be ASCII 128 anymore, is it?
ASCII doesn't have any characters beyond 0x7f AFAIK, but it doesn't
matter, I get what you mean. \xF0 in unicode mode would be U+00F0 of
course. Now how preg_match should handle it
On Mon, July 9, 2007 3:13 am, Alexey Zakhlestin wrote:
On 7/9/07, Richard Lynch [EMAIL PROTECTED] wrote:
Anybody who actually NEEDS Unicode ought to be the ones who have to
type a new keyword or something, not the bazillion users who have no
need for Unicode and likely never will...
I
On Mon, July 9, 2007 1:41 pm, Andrei Zmievski wrote:
Once again, you're trying to work with bytes inside Unicode strings,
which just does not make sense.
From our perspective, you've gone and changed a fundamental data
structure out from under us, in a non-backwards-compatible way, and
broken a
On Wed, July 11, 2007 3:11 am, Richard Quadling wrote:
On 11/07/07, Evert | Rooftop [EMAIL PROTECTED] wrote:
Larry Garfield wrote:
Top 10 by what metric? If I had to guess based on market share,
I'd say
(unordered):
Drupal
Squirrelmail
WordPress
phpMyAdmin
MediaWiki
Joomla
On Tue, July 10, 2007 7:06 pm, Larry Garfield wrote:
If 90% of the strings in use would work fine if treated as unicode,
then it
would make sense to just always assume Unicode unless explicitly
specified
otherwise.
If that 10% includes enough users who have written millions of line of
code
On Mon, July 9, 2007 5:24 pm, Christopher Jones wrote:
I also think we shouldn't backport features to PHP5. We should
I believe the only serious reason FOR this is if you want to drop the
semantics OFF in PHP 6...
If getting new features requires upgrading to 6 and taking the Unicode
stuff
On Tue, July 10, 2007 11:30 am, Andi Gutmans wrote:
What I really think we need to do for this release, which we haven't
been good at doing in the past, is build a PHP Compatibility Team
which
tries to port many applications to PHP 6 and finds the issues in doing
this port (both with
Seems to me...
Both need to be done.
Do both, or pick one if you can't do both, and somebody else will do
the other. That's how FLOSS works. :-)
On Wed, July 11, 2007 12:33 am, Evert | Rooftop wrote:
One final question..
should I assume while converting code unicode.semantics is on or
off?
On Wednesday 11 July 2007, Richard Lynch wrote:
And did I dream the thread on this way back when where it was stated
that Unicode was backwards-compatible, so this wouldn't be a problem?
Yet now it seems that UTF-16 is *not* backwards-compatible, and this
seems like a pretty big problem to
Is there a reason why the last 10 messages on this thread are coming from you?
It might just be me, but answering in the same email would be great.
Olivier
On 7/11/07, Richard Lynch [EMAIL PROTECTED] wrote:
Seems to me...
Both need to be done.
Do both, or pick one if you can't do both, and
Richard Lynch wrote:
On Tue, July 10, 2007 7:06 pm, Larry Garfield wrote:
If 90% of the strings in use would work fine if treated as unicode,
then it
would make sense to just always assume Unicode unless explicitly
specified
otherwise.
If that 10% includes enough users who have written
Unicode code points can be defined with \u, but PHP6 breaks
existing octal and hex escape sequences.
I don't understand what this means...
I think I know...
I have code like this, somewhere:
if (preg_match(|[\xF0-\xFF]|, $data)){
$data = un_microsuck($data);
}
un_microsuck()
Because he's Richard. He always does that. You should see him on
php-general. :-)
On Wednesday 11 July 2007, Olivier Hill wrote:
Is there a reason why the last 10 messages on this thread are coming from
you?
It might just be me, but answering in the same email would be great.
Olivier
On Mon, 9 Jul 2007, chris# wrote:
On Mon, 9 Jul 2007 14:38:03 -0700, Andrei Zmievski [EMAIL PROTECTED] wrote:
Yes, backporting major features from PHP 6 to 5 will slow down PHP 6
adoption, and I'd like to avoid it if possible.
There is a way to run two engines side by side, by the way:
On Mon, 9 Jul 2007, Nicolas Bérard-Nault wrote:
Permit me to give my 2 cents on that and share my small bit of experience
with PHP 6.
First of all, I totally agree with you Antony. I'm currently working on
deploying a big codebase in PHP 6 (for those of you who didn't know, I'm the
GSoC
On Tue, 10 Jul 2007 07:02:15 +0200, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 10.07.2007, at 01:19, chris# wrote:
On Mon, 9 Jul 2007 14:38:03 -0700, Andrei Zmievski
[EMAIL PROTECTED] wrote:
Yes, backporting major features from PHP 6 to 5 will slow down PHP 6
adoption, and I'd
On Tue, 10 Jul 2007 08:39:10 +0200 (CEST), Derick Rethans [EMAIL PROTECTED]
wrote:
On Mon, 9 Jul 2007, chris# wrote:
On Mon, 9 Jul 2007 14:38:03 -0700, Andrei Zmievski
[EMAIL PROTECTED] wrote:
Yes, backporting major features from PHP 6 to 5 will slow down PHP 6
adoption, and I'd like
On 7/10/07, Derick Rethans [EMAIL PROTECTED] wrote:
You can do that with fastcgi and lighttpd, not with apache.
not true.
you can do that with ANY server which uses fastcgi (apache can do that too!)
actualy, I believe fastcgi-mode should get some advertising from
php.net as it really have
On Tue, 10 Jul 2007, Alexey Zakhlestin wrote:
On 7/10/07, Derick Rethans [EMAIL PROTECTED] wrote:
You can do that with fastcgi and lighttpd, not with apache.
not true. you can do that with ANY server which uses fastcgi (apache
can do that too!)
Actualy, I believe fastcgi-mode should
I was thinking a bit more about this yesterday. Even if I'd agree with
this discussion (which I don't at this point in time) I think it is
being had far too early. We currently have a very big problem with
ability to upgrade to PHP 6 and making decisions without people actually
getting their feet
Andi Gutmans wrote:
What I really think we need to do for this release, which we haven't
been good at doing in the past, is build a PHP Compatibility Team which
tries to port many applications to PHP 6 and finds the issues in doing
this port (both with unicode_semantics=on/off). We can then
On Mon, 2007-07-09 at 19:38 -0700, Andi Gutmans wrote:
Btw, I don't know how many of you have actually tried to port PHP 5 apps
to PHP 6 but it's quite a disaster. We made some fixes in the past 2-3
weeks and its getting better but it still requires a lot of work. If we
don't make this easy
I think the sooner the better as it's valuable information for the dev
team.
It'd probably be a good idea to have a Wiki where we can document issues
that/common use-cases which are encountered.
Maybe we should have a Wiki on one of the php.net servers for such
purposes?
Andi
-Original
On Monday 09 July 2007, Stanislav Malyshev wrote:
Do _I_ like that horrible IS_STRING/IS_UNICODE mess we have atm? No.
I don't think there's any way of having both unstructured character data
and Unicode text represented without having two distinct types. Either
that or you'd have to tell on
Andi Gutmans wrote:
I think the sooner the better as it's valuable information for the dev
team.
It'd probably be a good idea to have a Wiki where we can document issues
that/common use-cases which are encountered.
Maybe we should have a Wiki on one of the php.net servers for such
purposes?
Andi
On Tue, 10 Jul 2007 20:55:30 -0400, Evert | Rooftop [EMAIL PROTECTED] wrote:
Andi Gutmans wrote:
I think the sooner the better as it's valuable information for the dev
team.
It'd probably be a good idea to have a Wiki where we can document issues
that/common use-cases which are
On Tuesday 10 July 2007, Evert | Rooftop wrote:
Andi Gutmans wrote:
I think the sooner the better as it's valuable information for the dev
team.
It'd probably be a good idea to have a Wiki where we can document issues
that/common use-cases which are encountered.
Maybe we should have a
Larry Garfield wrote:
Top 10 by what metric? If I had to guess based on market share, I'd say
(unordered):
Drupal
Squirrelmail
WordPress
phpMyAdmin
MediaWiki
Joomla
PHPBB
That will keep me busy =)
Evert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
One final question..
should I assume while converting code unicode.semantics is on or off?
If its on I would be making sure everything is properly casted to binary
strings where this is needed, if it's off the focus would be on making
sure the application runs on both PHP5 and PHP6..
What
On Fri, July 6, 2007 1:23 am, Stanislav Malyshev wrote:
You mean this will break:
?php
$mask = 0xf0;
$value = $_POST['foo'] $mask;
?
because of Unicode?
I'd say it won't do what it did before. Though I'm not sure bit
operations on unicode make any sense at all... The problem here
On Fri, July 6, 2007 11:48 am, Antony Dovgal wrote:
On 06.07.2007 20:44, Stanislav Malyshev wrote:
You don't by a Porsche if you need a taxi, why would you install
PHP6 if
you don't need Unicode?
Namespaces ;)
This reason is only valid if we don't backport such things from PHP6
to PHP5
Maybe strings should be UTF-8 until declared otherwise or something,
because this just won't fly...
UTF8 would not help you with bits (since nobody guarantees you incoming
data is valid UTF-8) and it's impossible to do any unicode stuff on
utf-8 - you'd have to convert it to utf-16 and back
It adds only the Unicode feature that a tiny niche market needs,
because everything else will be back-ported to PHP 5.
I'm not sure assumption that unicode is needed only for tiny niche
market is entirely correct.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
Unicode code points can be defined with \u, but PHP6 breaks
existing octal and hex escape sequences.
I don't understand what this means...
I think I know...
I have code like this, somewhere:
if (preg_match(|[\xF0-\xFF]|, $data)){
$data = un_microsuck($data);
}
un_microsuck()
On 7/9/07, Richard Lynch [EMAIL PROTECTED] wrote:
Anybody who actually NEEDS Unicode ought to be the ones who have to
type a new keyword or something, not the bazillion users who have no
need for Unicode and likely never will...
I wonder whom do you mean here.
I can't remember many
Once again, you're trying to work with bytes inside Unicode strings,
which just does not make sense. What do you propose we do, somehow
automatically detect that you used \x inside a Unicode string and
turn it into a binary one? Or simply allow one to stick any byte
sequence inside what is
Yes, backporting major features from PHP 6 to 5 will slow down PHP 6
adoption, and I'd like to avoid it if possible.
There is a way to run two engines side by side, by the way: in
separate instances of Apache. It's really not that complicated.
-Andrei
On Jul 6, 2007, at 6:13 AM, Stefan
As we see now, yes they will be in PHP 6.
-Andrei
On Jul 6, 2007, at 7:28 AM, Stefan Priebsch wrote:
Pierre schrieb:
Namespace is one _very_ important reason. If we need a marketing
I agree. But AFAIK namespaces were not supposed to be in PHP6, at
least
not in PHP 6.0. Is there an
And I think that we shouldn't, since it removes a big incentive for
people to move to PHP 6.
Really, we need to get folks to use Unicode natively as much as
possible. It is the way of the future, and not some obscure
feature, as some here have suggested. This kind of attitude is
On 10.07.2007 01:48, Andrei Zmievski wrote:
And I think that we shouldn't, since it removes a big incentive for
people to move to PHP 6.
I don't really see much sense in forcing people to use PHP6 if we accept the PHP5 =
PHP6 - Unicode formula.
They are just different things, period.
Andrei Zmievski schrieb:
As we see now, yes they will be in PHP 6.
:-))
--
e-novative - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
PHP Internals - PHP Runtime
I also think we shouldn't backport features to PHP5. We should
(i) keep PHP5 a stable release with a known feature set for developers
to use.
(ii) have a smaller code base to maintain in PHP5, reducing the
overhead of merging.
(iii) avoid exacerbating the future situation with uptake of PHP6
On Mon, 9 Jul 2007 14:38:03 -0700, Andrei Zmievski [EMAIL PROTECTED] wrote:
Yes, backporting major features from PHP 6 to 5 will slow down PHP 6
adoption, and I'd like to avoid it if possible.
There is a way to run two engines side by side, by the way: in
separate instances of Apache.
1 - 100 of 217 matches
Mail list logo
