Christian Schneider wrote:
Andi Gutmans wrote:
Maybe in a purists view it's not great, but in real life, many many many
users run more than one application on the same PHP server. Not
supporting
per-request Unicode in PHP 6 is going to be a huge mistake and will just
screw our users, most of them not purists nor hackers..
I agree with you there and I hope you can convince the others to accept
the patch...
It's not really about purism. It is about whether we can pull it off
effectively. Safe-Mode, if actually safe, would help lots of users as
well, but after many years of trying we have thrown in the towel on it.
I worry whether attempting to get the best of both worlds here is
another unreachable dream. Nobody is debating the merits of the idea,
so restating yet again doesn't really do anything for the discussion.
I worry about things that persist requests and how they will be affected
by unicode semantics changing out from underneath it. For example,
persistent database connections. They are created with a set of
credentials which are compared on the subsequent requests to see if the
existing connection can be re-used. With Unicode semantics flipping
back and forth will this comparison now fail even though the credentials
might actually match?
How about cache opcode arrays. I don't see a flag in the op_array that
says whether it was created in Unicode mode or not. Think about the
case where the same include file is included in both Unicode and
non-Unicode mode.
How about the hundreds of extensions out there that do things in MINIT
that persist across the life of the server. They would all have to be
reviewed to make sure they aren't making assumptions at startup that
aren't valid in the other mode. And worst-case and bunch of these would
have to be moved from MINIT to RINIT to get around this.
These are the sorts of things that the patch doesn't address that we
should be talking about, not whether it would be a useful feature to
users. We all agree it would be, but having a half-working feature
wouldn't be.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
