Пхп 6: Торгмаш Печь ротационная ПХП-6

Содержание

PHP 6 не будет, не осилили / Хабр

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

Так вот PHP 6 не будет, вообще. 11 марта 2010 команда разработчиков приняла решение об отмене выпуска PHP 6 в текущем его виде. В результате транк с PHP 6 был перенесён в бранч, а в транке образовалась новая версия — 5.4, в которую разработчики перенесли все наработки из PHP 6, кроме юникода.

Ниже приведен краткий пересказ презентации (pdf), сделанной Andrei Zmievski на PHP Community Conference в 2011 году.

Но для начала рассмотрим как юникод поддерживается сейчас

В исходном коде:
- Можно использовать в названии функций и переменных нелатинские символы, попадающие под регулярку [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*. Следующий код абсолютно валиден: function привет(){}
- Нормально обрабатываются документы с UTF-8 BOM, но только если нет пустых строк, иначе произойдёт отправка заголовков. Чтобы избежать этого рекомендуется держать HTML-код в шаблонах, а в самих PHP-файлах не использовать закрытие PHP-тега ?>
При обработке строк:
- Стандартные строковые функции, нормально переваривают как минимум UTF-8, но с символами работать не умеют, поэтому такие вещи как определение позиции символа или размера строки будут работать не правильно.
- Стандартное расширение xml умеет перегонять текст из UTF-8 в ISO-8859-1 и обратно, но по сути это бесполезный функционал.
- Расширение mbstring (Multibyte String), которое поддерживает большинство кодировок, включая юникодовые. Правда обычно оно не включено по умолчанию.

Общий смысл презентации

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

Так а в чём проблема спросите вы? Есть mbstring, используй и радуйся.
А дело в том, что разработчики решили поддержать юникод не на уровне библиотеки, а на уровне ядра.

Это означает, что любая php-функция, а также строковые операторы, в потенциале, могут принимать в себя юникод и более менее гарантировать, что юникод символы не будут исковерканы, удалены и не произойдёт ошибки. Кроме того, сам mbstring реализует далеко не все стандартные строковые функции.

Взгляните на следующий примеры:

и

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

Выбор кодировки

UTF-8 — Достоинства: обратная совместимость в ASCII, преобладающая кодировка в вебе, есть много библиотек, поддерживающих её.
UTF-16 — Достоинства: внутренняя кодировка библиотеки ICU, которая была выбрана для юникода и используется крупными игроками в вебе.
UTF-32 — Достоинства: прямая индексация.

В результате выбор пал, на UTF-16 из-за библиотеки ICU. Надо отметить, что оглядываясь назад, разработчики заявили, что если бы им дали сделать выбор ещё раз, то они выбрали бы UTF-8, так как режим обратной совместимости снизил бы объём работы.

Что пошло не так

Во-первых: достаточно мало специалистов, которые понимают тонкости юникода и использования ICU.
Во-вторых: это технически сложная задача встроить юникод везде.
В-третьих: люди просто устали вставлять поддержку юникода и в без того прекрасно работающий код.

Результат

Поскольку в культуре PHP-разработчика принято фокусироваться на интересной работе, а поддержка юникода не является интересной работой, то проект выдохся.

Будущее

Расширение mbstring неполноценно. Можно написать отдельный класс для работы с юникодом, но это также будет не полноценно. Поэтому как именно нужно поддерживать юникод в PHP сейчас всё ещё открытый вопрос.

Выученные уроки

Переписывать очень много работающего кода — трудно.
Заставлять людей делать утомительные вещи — трудно.
Ожидать результаты от вышеописанной деятельности, длящейся долгое время — трудно.
Будьте преданны (stay committed).

Не устанавливается последняя версия PHP на BitrixVM

BitrixVM — полностью настроенный виртуальный сервер, который адаптирован для работы с продуктами 1С-Битрикс. Его можно установить самостоятельно или воспользоваться VPS с готовым образом на сайте REG.RU.

BitrixEnv — окружение, которое находится внутри BitrixVM. Оно помогает устанавливать всё необходимое ПО и оптимизирует настройки для работы 1C-Битрикс.

Стабильная версия BitrixEnv работает на версии PHP 7.2. В свою очередь 1С-Битрикс уже может работать с более новыми версиями. При входе в админку CMS просит обновить версию PHP. В этой ситуации требуется сделать выбор:

Подождать стабильную версию BitrixEnv с новой версией PHP и обновить всё вместе.
Воспользоваться бета-версией BitrixEnv.

Beta-версия программы нестабильна. В ней могут быть недоработки. Компания REG.RU не несёт ответственности за эти ошибки. Если вы не готовы столкнуться с трудностями, подождите стабильную версию.
После установки бета-версии вернуться обратно на стабильную нельзя. Вам придётся ждать выхода новой стабильной версии и переходить на неё или устанавливать прежнюю стабильную версию заново.
Перед настройками сделайте резервную копию сервера. Например, на VPS можно воспользоваться снэпшотами.

Если вам подходит второй вариант, ниже мы дадим инструкцию для CentOS 7, как использовать новую версию PHP на BitrixVM.

Обратите внимание! Если вы используете CentOS 6, обновить PHP до версии 7.4 в BitrixEnv

нельзя.

Настройка состоит из трёх этапов:

Обновление BitrixEnv до последней стабильной версии.
Переход на beta-версию BitrixEnv.
Обновление версии PHP.

Этап 1. Обновите BitrixEnv до последней стабильной версии

Если у вас уже установлена последняя стабильная версия BitrixEnv, сразу переходите к этапу 2. Чтобы перейти к новой стабильной версии:

org/HowToStep»> 1.
Подключитесь к серверу по SSH.
2.
Перейдите в меню Bitrix. Если меню не запущено, откройте его с помощью команды:
```
/root/menu.sh
```
3.
Выберите пункт 2. Configure localhost settings, затем 6. Update server:
4.
Для подтверждения действий нажмите y:
5.
Сервер начнёт проверять версии пакетов. Если чего-то не хватает, он начнёт обновление. После обновления нажмите ENTER:
6.
Далее сервер вернёт вас к предыдущему меню. В запросе Please confirm you want to update the server нажмите N:
org/HowToStep»> 7.
Вернитесь в главное меню. Для этого выберите 0. Previous screen or exit:

Готово, переходите к этапу 2.

Этап 2. Перейдите на beta-версию BitrixEnv

1.
Выберите пункт 1. Manage servers in the pool, затем 10. Enable or disable bitrix-env beta versions
:
2.
Выберите пункт 1. Enable bitrix-env beta versions.
3.
Для подтверждения обновления введите y:
4.
Снова обновите пакеты. Выберите пункт 2. Configure localhost settings, затем 6. Update server:
org/HowToStep»> 5.
Для подтверждения действий нажмите y:
6.
Сервер начнёт проверять версии пакетов. Если чего-то не хватает, он начнёт обновление. Как только обновление завершится, появится надпись Complete!.
7.
После обновления нажмите ENTER:
8.
В запросе Please confirm you want to update the server нажмите N:

Готово, начнётся процесс обновления.

Чтобы отслеживать обновление в главном меню, выберите пункт 10. Background pool tasks. Статус running ― операция выполняется, finished ― операция завершена.

Если в процессе обновления возникла ошибка (статус Error), попробуйте запустить обновление повторно. Если проблема не будет решена, обратитесь в службу поддержки. В заявке укажите данные для доступа к серверу, чтобы специалисты смогли найти проблему.

Этап 3. Обновите версию PHP

1.
В основном меню выберите пункт 1. Manage servers in the pool
, затем 8. Update PHP and MySQL.
2.
Введите имя хоста, для которого нужно обновить PHP или введите all для обновления всех хостов:
3.
Выберите 1. Upgrade PHP:
4.
Выберите пункт 1. Update PHP to version 7.4:
org/HowToStep»> 5.
Чтобы подтвердить обновления, введите y для подтверждения обновления:

Установка может занять некоторое время. Чтобы отслеживать обновление в главном меню, выберите пункт 10. Background pool tasks. Статус:

running ― операция выполняется,
finished ― операция завершена,
error ― произошла ошибка. Обратитесь в службу поддержки.

Готово, последняя версия РНР установлена.

Помогла ли вам статья?

Да

раз уже
помогла

PHP: rfc:php6

Версия: 2.0
Дата: 05.07.2014 (последний 22.07.2014)
Авторы: Андреа Фолдс [email protected], Зеев Сураски [email protected]
Статус: Принято (имя PHP 7)
Впервые опубликовано на: http://wiki.php.net/rfc/php6

Введение

Были некоторые споры о том, как должен называться следующий основной выпуск PHP, который придет на смену серии PHP 5. x. это RFC — это попытка решить вопрос раз и навсегда.

В этом RFC предлагается, чтобы следующая основная версия PHP называлась либо PHP 6, либо PHP 7, в зависимости от результатов этого голосования. В следующем аргументы для обеих сторон представлены.

Исторический контекст

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

Эта предыдущая попытка создания новой основной версии также была разработана под названием PHP 6, и поэтому на нее ссылаются различные ресурсы, в том числе ряд книг. Есть опасения, что может возникнуть путаница между прерванной предыдущей попыткой и работой, которая ведется в настоящее время.

Чехол для PHP 7

Обоснование выбора версии 7 в качестве следующей основной версии PHP состоит из двух ключевых элементов: нет веских причин не делать этого, и есть несколько веских причин сделать это.

Нет веских причин НЕ пропускать версию 6

Что касается первого элемента, кажется, что многие люди обеспокоены тем, что если мы пропустим версию, мы каким-то образом вызовем путаницу или откажемся от нашей схемы управления версиями.

Основная путаница, на которую ссылались сторонники «PHP 6», заключалась в том, что люди будут задаваться вопросом: «Почему у нас вдруг появился PHP 7 и не было PHP 6?» — однако, это действительно больше вопрос пустяков, чем повод для путаницы. По понятным причинам будет ясно, что 7 — это последняя версия, и даже если есть 6, 7 новее и лучше.

Мы также не собираемся отрываться или даже менять нашу текущую схему управления версиями. Мы пропускаем только версию, сохраняя при этом все, что касается нашей схемы управления версиями.

Серьезные причины, по которым мы действительно должны пропустить версию 6 до версии 7

Есть несколько причин, по которым мы не должны повторно использовать версию 6 для следующей основной версии PHP.

Во-первых, PHP 6 уже существовал, и это было что-то совершенно другое. Десятичная система (или, точнее, бесконечный запас чисел, который у нас есть) позволяет нам легко пропустить версию, оставив еще много для будущих версий.
Хотя это правда, что другой PHP 6 так и не стал общедоступным, он по-прежнему был очень широко опубликованным и известным проектом, проводимым php.net, который не имеет абсолютно ничего общего с обсуждаемой сейчас версией. Любой, кто знал, что такое PHP 6 (а таких много), будет иметь сильное заблуждение относительно содержания и возможностей этой новой версии (по сути, это все о Unicode).
PHP 6, оригинальный PHP 6, подробно обсуждался на многих конференциях по PHP. Пользователей учили этому как готовому делу, включая подробные объяснения функций и поведения (разработчиками php. net, а не авторами «злых» книг).
PHP 6 был широко известен не только в сообществе Internals, но и в сообществе PHP в целом. Это был известный проект, о котором знали многие, если не большинство, члены сообщества PHP.
В Интернете есть много информации о PHP 6, об оригинальном PHP 6. Книги составляют наименьшую часть проблемы.
В отличие от «пустякового вопроса» «почему мы перескочили на 7?», повторное использование версии 6, скорее всего, вызовет реальная путаница в умах людей, с достаточным количеством информации о двух совершенно разных версиях с совершенно разными наборами функций, которые имеют одно и то же имя.
Пропуск версий не является беспрецедентным или необычным как в проектах с открытым исходным кодом, так и в коммерческих продуктах. MariaDB полностью перешел на версию 10.0, чтобы избежать путаницы, Netscape Communicator пропустил версию 5.0 сразу до версии 6.0, а Symantec пропустил версию 13. У каждого из них были разные причины для пропуска, но общий знаменатель заключается в том, что пропуск версий вряд ли имеет большое значение.
Версия 6 обычно ассоциируется с неудачей в мире динамических языков. PHP 6 потерпел неудачу; Perl 6 потерпел неудачу. На самом деле это связано с неудачей и за пределами мира динамических языков — MySQL 6 тоже существовал, но так и не был выпущен. Восприятие версии 6 как провала — не как суеверия, а как реальность реального мира (аналогично ассоциации слова «Vista» с провалом) — плохо отразится на этой версии PHP.
Обоснование версии 6 в основном является опровержением некоторых пунктов выше, но без веских доводов в пользу того, почему мы *не должны* пропускать версию 6. Если мы перейдем к PHP 7, в худшем случае мы будем без необходимости пропустил версию. У нас по-прежнему будет бесконечный запас основных версий для будущего использования. Если, однако, мы выберем 6 вместо 7 — в худшем случае это широкое замешательство в нашем сообществе и возможное негативное восприятие этой версии.

Как особый несерьезный бонус, 7 воспринимается как счастливое число как в западном мире, так и в китайской культуре. Немного удачи еще никому не повредило. http://en.wikipedia.org/wiki/Numbers_in_Chinese_culture (нет, на самом деле мы не рассматриваем это как реальное преимущество — доводы в пользу 7 очень сильны без него).

Сводка

Версия 6 уже используется широко разрекламированным проектом, который находится в умах очень большого количества PHP-разработчиков, внутренних специалистов и общего PHP-сообщества.

Мы ничем не рискуем, называя его PHP 7. Мы рискуем запутаться и получить негативное восприятие, если будем настаивать на повторном использовании 6 для совершенно другого проекта.

Идти на риск, который не принесет абсолютно никакой выгоды, — не лучшая стратегия.

Дело для PHP 6

В соответствии с нашим текущим процессом выпуска и семантическим управлением версиями, следующей основной версией после PHP 5 должен быть PHP 6. Если нет очень веских причин для обратного, мы не должны отказываться от нашей текущей версии схема нумерации.
Хотя существует ряд ресурсов о предыдущей попытке выпуска PHP 6, они будут быстро заменены, как только PHP 6 действительно будет выпущен. Это относится как к сообщениям в блогах, которые будут (и частично уже) вытеснены более новым контентом, так и к книгам, которые получат отрицательные отзывы, потому что они на самом деле не охватывают ту версию PHP, которую, как они утверждают, охватывают.
К настоящему времени также существует множество ресурсов, которые ссылаются на следующую основную версию как на «PHP 6», не имея никакого отношения к заброшенной предыдущей попытке. Это включает в себя все, что угодно, от сообщений в блогах и обсуждений функций будущей версии до RFC и проектных документов в этой вики. Называние следующей основной версии «PHP 7» вызовет путаницу в этом направлении.
В обсуждениях OTR новой основной версии она почти всегда упоминается как «PHP 6». Учитывая, что текущая версия — PHP 5, люди по понятным причинам делают вывод, что следующей будет «PHP 6», и называют ее таковой. В умах многих разработчиков «PHP 6» уже глубоко укоренилось как название следующего крупного проекта.
В то время как многие участники внутреннего списка рассылки были вовлечены в первоначальную разработку PHP 6 и поэтому хорошо осведомлены о его существовании, более крупное сообщество PHP этого не знает. При обсуждении этого RFC с разными разработчиками, многие толком не понимали, зачем это вообще вопрос, ведь они лишь смутно осознавали, что в прошлом было что-то вроде PHP 6. Таким образом, ошибочные ожидания из-за путаницы с номером версии должны быть минимальными.
Хотя прецедент отсутствующих номеров версий, безусловно, был, обычно это происходит в контексте более значительных изменений в схеме управления версиями. Например, когда Java перешел с 1.4 на 5.0, стало ясно, что изменилась система нумерации. Существующий прецедент предлагает перейти на PHP 2016 или что-то столь же отличное, а не просто пропустить версию. (Нет, это не серьезное предложение.)

Голосовать

Предлагается голосование 50%+1 (простое большинство) с двумя вариантами: «PHP 6» и «PHP 7». Если больше голосов будет за PHP 6, это будет название следующего основного выпуска PHP. В противном случае, если больше голосов будет за PHP 7, это будет его имя.

Голосование началось 20 июля 2014 г., но было отменено.

Голосование возобновилось 23 июля 2014 г. и закончилось 30 июля 2014 г.

Имя PHP NEXT должно быть PHP 6 или PHP 7?
Настоящее имя	PHP 6	PHP 7
аб (аб)
эорис (aeoris)
ахарви (ахарви)
айф (айф)
амир (амир)
энди (анди)
ашназг (ашназг)
аврореосроза (auroraeosrose)
Барри Карлайон (barrycarlyon)
бате (бате)
епископ (епископ)
брэндон (брэндон)
Брайанлмун (brianlmoon)
холоднее (холоднее)
Дэйви (Дэви)
дерик (дерик)
дм (дм)
дмитрий (dmitry)
драгунис (dragoonis)
Эрикстен (ericsten)
фа (фа)
Фабьен Потенсье (fabpot)
фмк (фмк)
замороженный огонь (замороженный огонь)
гуглгай (гуглгай)
гильермебланко (guilhermeblanco)
гвинн (gwynne)
ххольцгра (hholzgra)
градке (hradtke)
хайван (hywan)
ифегали (ifeghali)
индейец (индейец)
иттребал (itrebal)
ivonascimento (ивонасименто)
джедибк (джедибк)
жмикола (жмикола)
jwage (jwage)
калле (калле)
каплан (каплан)
Крискрейг (Крискрейг)
ларуенс (ларуэнс)
лешек (лешек)
левим (левим)
стройный (стройный)
малукеньо (malukenho)
марко (марко)
матвиль (матвиль)
мбеккати (mbeccati)
мфонда (мфонда)
мгс (мгс)
Майк (Майк)
МайкМайк (Майкейк)
мрук (мрук)
никик (никич)
паджойе (pajoye)
патрикалларт (патрикалларт)
пихаа (пихаа)
филсту (филсту)
поллита (поллита)
преинхаймер (преинхаймер)
Рэмси (Рэмси)
рдлоури (rdlowrey)
ром (ром)
рейвоб (рейвоб)
шон (шон)
себастьян (себастьян)
продано (продано)
шестой (шестой)
собака (собак)
стас (стас)
sthulbourn (стулборн)
саркос (саркос)
торстенр (thorstenr)
tony2001 (тони2001)
треффиннон (треффиннон)
тираэль (тираэль)
вейерофинней (weierophinney)
что Джефф (что Джефф)
йогаки (йогаки)
юнош (юнош)
замолксе (замолксе)
зеев (зеев)
Конечный результат:	24	58
Этот опрос был закрыт.

Ссылки

Список внутренних компонентов: О PHP6 (апрель 2014 г.)
Amazon поиск книг «PHP6»