Хороший… Плохой… Главное — у кого ружьё!
6,4
рейтинг
30 июля 2014 в 12:30

Разработка → Следующая версия PHP будет называться PHP 7

imageДолгий спор вокруг названия следующей версии PHP сегодня наконец-то закончился: итак, следующая версия будет иметь порядковый номер 7.

В основу PHP7 ляжет PHPng. Многие из свежих предложений и патчей делаются уже на его базе — в том числе такие интересные вещи, как uniform variable syntax, native big integers и abstract syntax tree. Из-за изменений во внутренних API, многие сторонние расширения (например, xdebug, расширения для mongodb и memcached, php-protocolbuffers) должны быть переработаны, поэтому в PHP 5.7 PHPng войти уже не сможет. Казалось бы, проблема не так велика — но, например, Yahoo в своих разработках использует около 400 различных PHP-расширений, поэтому процесс должен занять некоторое время.

Когда зашел вопрос о выборе номера для следующей версии PHP, разработчики сразу вспомнили о предыдущей попытке сделать PHP 6, которая стартовала в 2005 году и была прекращена в 2010 из-за сложностей с реализацией поддержки Юникода. Поэтому все нововведения PHP6, кроме той самой поддержки, были потом реализованы в PHP 5.3 и PHP 5.4

Но из-за этой неудачи против названия PHP 6 аргументы нашлись быстро: на Амазоне до сих пор полно книг «Learn PHP6 in 1 hour», которые нынче годятся разве что на растопку печи; о «заброшенной» PHP6 в прошлом было много докладов на конференциях; да и в целом — все то, что было написано о PHP 6 до 2010 года — никуда не делось и создало бы лишнюю путаницу вокруг релиза. Если забыть о том, что вопрос «Почему после PHP 5 был PHP 7?» рискует вскоре поселиться среди самых популярных тем на Тостере и StackOverflow, то объективных причин не пропускать версии у core developers в итоге не нашлось.

RFC
Владимир Маслов @HotWaterMusic
карма
165,7
рейтинг 6,4
Хороший… Плохой… Главное — у кого ружьё!
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (62)

  • –34
    > на Амазоне до сих пор полно книг «Learn PHP6 in 1 hour»

    Спасибо Вам огромное — это просто великолепно!
    Как говорят у нас в интернетах, «ржушодурной»… :)
    • +2
      Один ревью прекраснее другого :)
  • +7
    Интересно, через сколько она теперь выйдет. Тот же PHPng вроде как еще пилить и пилить.
  • +2
    > и была прекращена в 2010 из-за сложностей с реализацией поддержки Юникода. Поэтому все нововведения PHP6, кроме той самой поддержки, были потом реализованы в PHP 5.3 и PHP 5.4

    Так а в семерке ее таки сделают же, да?
    • +7
      Нет.
      От этих планов в принципе отказались.
      • +46
        От этих планов в принципе отказались.

        Ну это уже совсем не серьезно — отказываться от поддержке юникода в языке сегодня!
        Я даже не буду пытаться язвить на счет PHP — они сами отлично все сделали ;)
        • +3
          Можно язвить, можно не язвить, это вкусовщина.

          Поддержку юникод необходимо было добавлять на этапе разработки ядра, теперь это попросту ломает всё.
          • +3
            А что вообще в себя включает «поддержка уникод»?
            • +2
              Нативная работа со всеми строками, как с уникодом — без костыльных решений, вроде mb_*, причем был выбран за основу UTF-16, что еще больше усложнило разработку. В итоге плюнули на это. Где-то был обширный пост, разъясняющий почему конкретно разработчики забили, но сейчас нет времени искать.
              • +4
                Есть такой пост: http://habrahabr.ru/post/138269/.
                • +1
                  Ага, нашёл там такое

                  Что хотелось иметь

                  Так а в чём проблема спросите вы? Есть mbstring, используй и радуйся.
                  А дело в том, что разработчики решили поддержать юникод не на уровне библиотеки, а на уровне ядра. Это означает, что любая php-функция, а также строковые операторы, в потенциале, могут принимать в себя юникод и более менее гарантировать, что юникод символы не будут исковерканы, удалены и не произойдёт ошибки. Кроме того, сам mbstring реализует далеко не все стандартные строковые функции.
                  • +1
                    Предположим, что в некотором скрипте PHP все строки содержат текст в кодировке UTF-8.

                    Если оставить в стороне вопрос о том, что PHP считает их размер в байтах, а не в символах, то что может пойти не так («символы исковерканы, удалены, ошибки») по сравнению со строками в обычной восьмибитной кодировке?

                    Может ли один символ найтись вместо другого? — нет, потому что в UTF-8 однобайтовые символы (ASCII-символы) имеют старший бит «0», а у многобайтовых последовательностей UTF-8 начальные байты имеют старшие биты «11», тогда как остальные байты (включая конечные) имеют старшие биты «10». Следовательно, перепутать эти три категории байтов кода никак нельзя.

                    Тогда что не будет работать, кроме подсчёта длины строк или позиции в строке? Я пока могу только один пример придумать: классы символов в регулярных выражениях.
                    • +2
                      Да нет особых проблем от того, что пхп работает со строками как с массивами байт. Проблемы появляются, когда само ядро языка пытаются научить работать с юникодом, что очень сильно усложняет код (ядра) и очень сильно бьет по производительности. В итоге становится понятна, что эта пресловутая «поддержка юникода» просто не стоит того.
                    • +6
                      Подсчёт длины строк не очень полезен, поскольку он идёт в кодпойнтах, а люди считают графемами (знак ударения — простейший пример: люди за символ его не считают. Впрочем, считать в кодпойнтах иногда тоже нужно, иначе можно забить БД zalgo в 5 миллионов кодпойнтов в каждом поле «ник», игнорируя ограничения в 15 графем). Проблемы будут при попытках делать с текстом хоть что-то (например, искать подстроку с учётом канонической эквивалентности либо сортировать, учитывая локаль), но об этих вещах даже в языках с «поддержкой юникода» нужно думать самим (нестареющий пример с перлом, многие вещи справедливы и для «умеющих юникод из коробки» языков). Поэтому именно решение не уметь юникод в ядре языка — вполне себе практичное. Позволит, в конце концов, писать более-менее эффективные библиотеки работы с протоколами (все служебные слова которых как правило в ASCII), используя все удобства работы со строками, а не как в python3: либо оверхэд на работу с юникодом (те же поиск и collation не бесплатны), либо байтстринги, у которых нет даже .format().

                      У PHP есть много минусов, но лично мне неумение юникода кажется не сильно страшным. Не понимаю, почему минусуют. Также неумение юникода в ядре позволит реализовывать любые кодировки уровнем выше без каких-либо ограничений.
                    • +1
                      Более того — и с регулярными выражениями вообще нет никаких проблем — в php используется библиотека pcre, и в любом регулярном выражении можно в явном виде задать unicode-режим (/u).
            • +7
              Возможность кодить на русском/китайском и с emoji
          • +4
            теперь это попросту ломает всё

            Ну выбор у создателей PHP не большой:
            * Сломать и сделать поддержку.
            * PHP-разработчики должны страдать! (дьявольский смех)

            Не выберут ли в этом случае сами PHP-разрабочики постепенную миграцию на тот же Python 3 (который пусть и с большим трудом но постепенно увеличивает свою долю)?
            • +3
              PHP выбирают не за поддержку юникода и, по моему мнению, этот вопрос встанет последним в принятии решения о миграции на другой язык. Не за это и питон выбирают :)
              • 0
                PHP выбирают не за поддержку юникода

                Полностью согласен — как и любой другой язык.
                Да и не думаю, что в ближайшие годы PHP «умрет» от отсутствия юникода.
                Вопрос немного в другом — при наличие альтернатив у разработчиков всегда закрадываются мысли посмотреть их, попробовать и кто знает к чему это приведет, если альтернативы окажутся более удобны (PHP все же не C/C++ от которых никуда не деться сейчас) ;)
            • 0
              А в чем выражаются ваши страдания? В том что не можете как в 1С писать?
              • –1
                Неужели формулировку «PHP-разработчики должны страдать! (дьявольский смех)» можно понять так буквально :) Просьба читать ее как: «PHP-разработчики должны испытывать некоторые неудобства».

                Выше есть ссылка на топик про отказ от юникода в PHP6. В комментариях упоминаются отдельные неудобства которые это создает, например этот комментарий.

                Лично я не являюсь PHP-разработчиком и в работе использую язык с поддержкой юникода. При возникновении необходимости что-то сделать на языке без поддержки юникода Python 2.x, C — сразу видно, что с юникодом жить приятнее. И надеюсь, что рано или поздно PHP разработчикам тоже облегчат жизнь.
                • –1
                  Понял, желать что: «PHP разработчикам тоже облегчат жизнь» — на Хабре нельзя, минусуют PHP-ненавистники ;)
              • +1
                В PHP, в принципе, и сейчас русские буквы в названиях функций/переменных отлично работают.
                • 0
                  Может быть, но вот символ «§» в именах классов (потому что «-» нельзя!) вызывает у нас (PHP 5.3) редкую и нерегулярную ошибку.
              • +3
                php.net/manual/en/language.variables.basics.php
                As a regular expression, it [variable name] would be expressed thus: '[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*'

                <?php
                $сколькоРаз = 5;
                
                $функция = function($значение) use ($сколькоРаз) {
                    printf("%d из %s\n", $значение, $сколькоРаз);
                };
                
                for ($номер = $сколькоРаз; $номер; --$номер) {
                    $функция($номер);
                }
                


                Прекрасно работает для utf8 исходника. Но так же делать не стоит?:)
          • +2
            Значит, надо ломать. Возможно, как питон, поддерживать две ветки некоторое время.

            Но любая другая стратегия — это отодвигание решения проблемы на потом. Причем, чем дольше отодвигают, тем сложнее будет решать (потому что больше сломается).
      • +6
        Как-то странно это, всё же. Что же это за сложности такие, что чуваки их никак не преодолеют? Учитывая опыт второго и третьего питонов (и набитых при этом шишек).
        • +13
          В посте есть ссылка на статью, там написано.
          Конечно же такие штуки как AST и native big integers важнее и нужнее в web-разработке чем какой-то там Юникод. Всякому понятно. :)
          • +6
            Почитал статью, спасибо за ссылку. Ну детские проблемы какие-то. Я согласен, что задача непростая, и тонкостей там вагон с тележкой (в тексте Армина Ронахера некоторые из них описаны достаточно подробно, чтобы оценить масштаб), но основные грабли в общем-то давно известны, и жаловаться на отсутствие специалистов по юникоду и неудачный выбор UTF-16 в 2014 г. уже как-то несерьезно.
            • +1
              Есть же дефолтные функции *_mb, почему бы их не использовать вместо стандартных? Сам пользую уже лет пять, как-то даже не заметил отсутствие нативной поддержки юникода если честно…
      • +1
        Я бы не был столь категоричен. Отказались в принципе от реализации юникода в PHP6 на базе UTF-16 в том виде, как они собирались. И, насколько я помню, когда официально было заявлено, что «шестерке — кирдык», то одной из ключевых причин назывался принципиально неверный подход к реализации поддержки юникода (в т.ч. и выбор UTF-16). Что будет в «семерке» и не будет ли предпринята новая попытка поддержать юникод, но с иным подходом — пока неизвестно. Или уже есть какие-то официальные заявления на этот счет?
        • +2
          Возможно вы правы, в wiki у них есть предложения по использованию 3rd-party библиотек, чтобы впилить поддержку utf-8 (а не 16) в ядро. Но они пока что только с именем и определились, а судя по проекту PHPNG их сейчас гораздо больше волнует производительность движка (на фоне неиллюзорной конкуренции со стороны HHVM)
  • +9
    Главное, чтобы не вышло как с питоном.
    • +2
      А что случилось с питоном? Что-то я не в курсе, где почитать?
      • 0
        Ну, например: habrahabr.ru/post/208192/
        • 0
          Ну так юникода, как раз, не будет. Имелась ввиду, вероятно, потеря обратной совместимости при переходе от Python 2 к Python 3.
          • 0
            А об обратной совместимости я даже писать не хотел. Я думал это и так очевидно :)
      • –2
        Случилось ужасное — он получил поддержку юникод ;) (в какой-то степени слово 'ужасное' действительно применимо — см. ссылку из соседнего комментария)
  • 0
    Вполне ожидаемо.
  • +9
    А у меня есть такой слоник)

    Слоник
    image
    • 0
      Откуда? У меня только синие.
      • +1
        На Kickstarter собирали:
        www.kickstarter.com/projects/eliw/php-architect-orange-elephpant
        Мы целый ящик заказали)). Получили, кстати, буквально на прошлой неделе.
        • 0
          Клево. А то у меня только три синих.
          • 0
            Главное, что не зелёных.
            • 0
              А что плохого в зеленых elePHPant'ах? :)
              • 0
                Да ничего, им просто плохо в клетке жить…
      • +2
        А мне подруга сама сшила двоих)
        s4.pikabu.ru/post_img/big/2014/06/05/11/1401993331_2136584611.jpg
        • 0
          Уникальные в своем роде)
    • НЛО прилетело и опубликовало эту надпись здесь
  • +5
    А вот в ядро Delphi поддержку Unicode запилили в версии Delphi 2009. Причем жестоко запилили: тип String, представлявший собой в предыдущих версиях строку однобайтных символов, вдруг стал строкой из символов 2-х байтных. И объем строки в байтах стал не Length(s), a 2*Length(s), а точнее SizeOf(Char)*Length(s), т.к. сам тип Char тоже превратился из 1 байта в 2. Это сразу сломало совместимость с новой версией большей части имеющихся проектов, но ничего, попыхтели немного — привели код в порядок, всё снова заработало, зато теперь Unicode не только в самом языке (во всех функциях, принимающих на входе строки), но и во всех визуальных компонентах, причем из коробки. Работать с этим довольно приятно.
    • +1
      То есть люди перешли на UTF-16, я правильно понимаю? Тогда (как и в JavaScript) их ждёт много небезынтересных откровений, связанных с существованием символов Unicode, имеющими номера более U+010000, для обозначения которых не достаточно двух байтов, не достаточно четырёх шестнадцатеричных цифр.
      • 0
        имеющими номера более U+010000

        Не следует путать кодовые точки (номера символов в таблице Unicode, которые могут быть > 65535) и кодировку (UTF-8, UTF-16), которой эти точки кодируются.

        Насколько я понимаю, UTF-16 так устроена, что для кодирования символов с кодом (кодовой точкой) > 65535 нужно использовать более одной пары байт. В обычных применениях такие символы (представленные суррогатными парами), как правило, не встречаются.

        Цитирую википедию:
        В UTF-16 символы кодируются двухбайтовыми словами с использованием всех возможных диапазонов значений (от 0 до FFFF16). При этом можно кодировать символы Unicode в диапазонах 000016..D7FF16 и E00016..10FFFF16. Исключенный отсюда диапазон D80016..DFFF16 используется как раз для кодирования так называемых суррогатных пар — символов, которые кодируются двумя 16-битными словами. Символы Unicode до FFFF16 включительно (исключая диапазон для суррогатов) записываются как есть 16-битным словом. Символы же в диапазоне 1000016..10FFFF16 (больше 16 бит) уже кодируются парой 16-битных слов. Для этого их код арифметически сдвигается до нуля (из него вычитается минимальное число 1000016). В результате получится значение от нуля до FFFFF16, которое занимает до 20 бит. Старшие 10 бит этого значения идут в лидирующее (первое) слово, а младшие 10 бит — в последующее (второе). При этом в обоих словах старшие 6 бит используются для обозначения суррогата. Биты с 11 по 15 имеют значения 110112, а 10-й бит содержит 0 у лидирующего слова и 1 — у последующего. В связи с этим можно легко определить к чему относится каждое слово.
  • +4
    То есть в существующем интерпретаторе PHP вообще нет AST?..
    • 0
      А зачем в интерпритаторе AST? Вообще да, в PHP довольно примитивный single-pass парсер. Наследие былых ошибок, так сказать.
      • 0
        Вообще забавно, помниться кода вопрос перехода на AST обсуждали в 2012-ом говорилось о снижении производительсности и необходимости использования опкод-кешеров. Судя по приведенным в RFC данным производительность разбора исходников наоборот увеличивается, причем потребление памяти вырастает незначительо, что не может не радовать.
      • 0
        Ну там же байткод генерируется, как я понимаю. Довольно типовая задача, и обычно проще решается именно с AST.
        • 0
          По сути. если мы рассматриваем именно интерпритатор, то он работает только с оп-кодом. AST — часть парсера/транслятора в опкоды. Вообще просто так повелось. Расмус Лердорф как-то говорил «I was really, really bad at writing parsers. I still am really bad at writing parsers». Так и повелось. Впервые о необходимости перехода на AST для парсеров заговорили довольно давно, вроде как в 2010-ом. К сожалению в 2012-ом решили что это слишком титанический труд и забросили это дело. Но с тех пор появилась почти готовая реализация оного, да и phpng это уже существенные изменения в ядре. Так что можно надеяться что в итоге перейдут на AST и расширять синтаксис PHP перестанет быть адской болью.
    • +1
      да, но скоро все изменится! wiki.php.net/rfc/abstract_syntax_tree
      • 0
        Собственно, это в посте написано.
  • –4
    testq

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.