On 28-Dec-2009, at 20:39, Ferenc Kovacs <tyr...@gmail.com> wrote:
On Mon, Dec 28, 2009 at 11:58 AM, jvlad <d...@yandex.ru> wrote:
Do you think we are deprecating split() just for fun?
Yes, exactly. It's just made for _fun_ by core developers and brought
headache
to people developing in php.
We are letting you know that you need to start thinking about
migrating
your code away from non-Unicode aware functions like ereg() and
split().
Well, this filled up my php logs with some million records telling
me this!
Do you think it's safer to keep thinking and have an opportunity to
miss
anything
dangerous in the logs just becase they are flooded.
The Web is going entirely Unicode as is PHP 6 and these functions
simply
do not
support Unicode strings. preg_split() is a decent substitute and
you
should be able to convert to it with only minor changes in your
regex.
If these changes are minor, why don't you provide a version of
split for
php6 that will make them
on the fly? Why don't you consider the other scenarios that would
maintain
the language BC?
And this has nothing to do with this thread. Please keep your
rants at
least somewhat on topic.
It has direct relation to this thread because it's all about the
policy of
the changes in the language.
Some pain changes are already done, some painless are not allowed.
Whould you please make your position more public and clearer?
as far as I see, the changes depends on how many work has to be done,
to preserve something.
posix functions like split, and so could have been modified to work
with the unicode strings, but nobody cared enough.
Besides, nobody's forcing you to "upgrade" to php6. Pragmatism applied
I would just retrofit split() to preg_split() in userland whenever not
defined, since by right pcre cannot be disabled ;-)
now this request is easier to leave this way, because this scenario
needs zero work against the proposed solutions.
but hey: patches are welcome!
:/
Tyrael
-jv
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
