Судьба PHP6

Поговорил с одним из разработчиков PHP по поводу судьбы PHP6, самое ожидаемое изменение которого — переход на юникодные строки. Так вот Антон Довгаль рассказал, что проект, по сути, заброшен. Те несколько человек, которые занимались проектом, либо уволились, либо потеряли к нему интерес и сейчас считается, что поддержка юникодных строк в языке не так уж и нужна.

На примере своего опыта разработки и перевода проектов на PHP на UTF-8, скажу это не так. В Пайтоне, где таких проблем нет, работать гораздо проще и приятнее.

То, что в PHP приходится для поддержки Юникода работать с UTF-8, а не с UTF-32 сильно снижает производительность всех строковых операций. И добро бы, если бы для всех функций были юникодные аналоги, так это ведь не так.

Работать в PHP с UTF-32 нельзя, если вы собираетесь использовать регулярные выражения: библиотека PCRE, предназначенная для работы с регулярными выражениями, понимает только две кодировки: latin-1 (по всей видимости) и UTF-8. Кроме того, функции, использующие локаль или ICU так же работают только с UTF-8.

Если бы этот язык нативно поддерживал UTF-32… Мечты-мечты.
16 декабря 2010 17:34

tony2001 (инкогнито)
16 декабря 2010, 17:44

Ну, я не совсем то говорил.
Я хотел сказать вот что - раньше был явно интерес к PHP6 со стороны нескольких компаний. Одна из них - Yahoo и Андрей Змиевский над ним плотно работал.
Потом Андрей сменил работу и (естественно) перестал тратить большую часть своего рабочего времени на PHP6.
Но это частный случай. Общая ситуация (на мой субъективный взгляд такова) - разработка PHP6 затормозилась в первую очередь потому, что в PHP уже есть mbstring, который при всех свой недостатках, решает 90% задач со строками в Unicode/и др. А остальные 10% задач требуют существенной переделки ВСЕГО кода.
При этом для работы со строками в PHP6 (кстати, не факт, что номер версии будет именно такой) используется ICU, которая тоже есть универсальное решение сферической задачи в вакууме, а оттого не блещет скоростью. Т.е. PHP6 за счет работы с юникодом потеряет еще N% производительности (а кому это надо?).

bolk (bolknote.ru)
16 декабря 2010, 17:49, ответ предназначен tony2001

Тем не менее, переход на массивы-классы выполняется (ArrayObject), а со строками такого движения не видно, хотя это был бы выход. Создать UnicodeString и тянуть в него методы для работы с Unicode, а кроме того, научить PCRE работать с такими строками. Уже было бы большое дело.

Victor Grinchik (wiktar.com)
16 декабря 2010, 17:51

PHP6 заброшен или поддержка юникода в нём?

tony2001 (инкогнито)
16 декабря 2010, 17:52, ответ предназначен Victor Grinchik (wiktar.com):

PHP6 == PHP + Unicode
"мы говорим PHP6, а подразумеваем Unicode" (c)

bolk (bolknote.ru)
16 декабря 2010, 17:53, ответ предназначен tony2001

Есть библиотека, которая с космической скоростью перекодирует из UTF-8 в UTF-16 с огромной скоростью: http://u8u16.costar.sfu.ca/

Сделать на её базе перекодировку из UTF-32 в UTF-8 и засунуть в класс UnicodeString, чтобы отдавать наружу UTF-8 по запросу.

tony2001 (инкогнито)
16 декабря 2010, 17:55

опять же, напрашивается отдельный экстеншен, т.к. это решение не универсальное =/

ExH (exh.myopenid.com)
16 декабря 2010, 17:55

А почему UTF-32, а не UTF-16?

bolk (bolknote.ru)
16 декабря 2010, 18:34, ответ предназначен ExH (exh.myopenid.com):

С UTF-16 неудобно работать.

Вкратце: UTF-16 — это 16 бит на символ с некоторыми исключениями (об этом дальше). В 16 бит помещается 65535 символов, а в Unicode их намного больше, как же кодировать остальные. Они кодируются так называемыми «суррогатными парами», часть кодов в UTF-16 имеют специальное значение, если они встречаются в строке, значит за ними идёт ещё символ.

Таким образом, длина символа в строке не всегда два байта. Это значит, что длину строки UTF-16 нельзя получить делением её байтовой длины пополам, нельзя адресоваться к символу, умножив смещение на 2 и так далее.

bolk (bolknote.ru)
16 декабря 2010, 18:35, ответ предназначен ExH (exh.myopenid.com):

Немного ошибся, значений в 16 битах 65536.

hshhhhh.name (hshhhhh.name)
16 декабря 2010, 19:53

я крайне сильно жду что в пхп6 приведут названия функций и порядок аргументов к одному виду. но это, похоже, без вариантов.

bolk (bolknote.ru)
16 декабря 2010, 19:59, ответ предназначен hshhhhh.name:

Варианты есть и туда PHP активно движется. Например, уже сейчас есть класс ArrayObject с нормальными методами, все названия camel case.

анонимус (инкогнито)
16 декабря 2010, 21:04

пхп6 приведут названия функций и порядок аргументов к одному виду
а не проще начать подымать новый апи для таких мегастрочек параллельно с тем что уже есть не трогая старое г-но.
пусть будет и то и то. пусть будет класс типа string как в java с регекспами внутри + системные классы для обработки?

кому надо полностью переползут на этот новый пи. старье будет какоето время на старом API жить.
Просто ИМХО глупо и дорого получается заставлять текущий апи работать по новому, да так чтобы выглядело в коде "по старому" и не было геммороя :)

bolk (bolknote.ru)
16 декабря 2010, 21:06, ответ предназначен анонимус

пусть будет и то и то. пусть будет класс типа string как в java с регекспами внутри + системные классы для обработки?
Ровно это сейчас и делается. Я же написал.

den_rad (den-rad.ya.ru)
17 декабря 2010, 11:16

Спасибо за информацию. Скорее я мигрирую на Python/Ruby, чем нормальный юникод появится в php

bolk (bolknote.ru)
17 декабря 2010, 11:48, ответ предназначен den_rad (den-rad.ya.ru):

Я уже больше пишу на Python и Powershell, чем на PHP.

Ваше имя или адрес блога (можно OpenID):

Текст вашего комментария, не HTML:

Кому бы вы хотели ответить (или кликните на его аватару)