Новая ветка интерпретатора языка программирования PHP 5.4 перешла (http://www.php.net/index.php#id2011-09-27-1) на стадию бета-тестирования. В новой ветке добавлены новые языковые конструкции и удалены устаревшие возможности, поэтому версия 5.4 не обеспечивает полную совместимость на уровне API и конфигурации. При использовании PHP 5.4 может потребоваться модификация приложений и серверных настроек (например, удалена поддержка Safe mode и register_globals).
Основные новшества (http://www.php.net/releases/NEWS_5_4_0_beta1.txt):
- Возможности, удаленные по причине их устаревания:
- Прекращение поддержки всех опций, связанных с режимом "Safe mode";- Прекращение поддержки синтаксиса "break/continue $var"
- Удаление конфигурационных опций
register_globals
, define_syslog_variables, highlight.bg, session.bug_compat42, session.bug_compat_warn, y2k_compliance, allow_call_time_pass_reference и register_long_arrays;- Удаление функций session_is_regisitered(), session_...
URL: http://www.php.net/index.php#id2011-09-27-1
Новость: http://www.opennet.me/opennews/art.shtml?num=31864
Язык эволюционирует.
> версия 5.4 не обеспечивает полную совместимость на уровне APIВот за это я очень не люблю этот язык. в Python 2.6 и Python 2.7 прекрасно запускается Zope3, в которой оставлена поддержка Python 2.4
> Вот за это я очень не люблю этот язык. в Python 2.6 и Python 2.7 прекрасно запускается Zope3, в которой оставлена поддержка Python 2.4Т.е. ты совместимость по версиям сравниваешь? ГСМ детектед. Кто сказал, что Питоноподобное версионирование правильное?
>> Вот за это я очень не люблю этот язык. в Python 2.6 и Python 2.7 прекрасно запускается Zope3, в которой оставлена поддержка Python 2.4
> Т.е. ты совместимость по версиям сравниваешь? ГСМ детектед. Кто сказал, что Питоноподобное
> версионирование правильное?потому что при каждом апгрейде версии необходимо думать, будет ли мелкий у клиентов на хостинге работать так же хорошо, как и в php5.4
Толи дело ява совместима до 1.0.2
я посмотрю, как ты на Java 7 запустишь что-нибудь из Java 5, Java 6. Ты почти сразу получишь откат, поскольку не совместимо. Уже жаловались на это (http://www.opennet.me/opennews/art.shtml?num=31340)
Вообще-то там были не проблемы с запуском, а проблемы с ключами оптимизации, в результате которого терялись циклы, точно такую же багу можно поймать и на 5й и на 6й яве, главное знать ключи (раньше по дефолту они были выключены, в 7ке по дефолту включили).А по поводу совместимости всё пучком, собирал 6й явой сорцы которые писались ещё для 1.2 и всё работает, это же кровавый энтерпрайз, там совместимость идёт в первую очередь и это одна из причин по которой дотнет так тяжело входит в эту область, вот там ты свежим дотнетом точно старые сорцы не соберёшь, уже не один раз на это натыкался.
У меня ничего не падает на 7, это какой-то специфичный баг, и его таки исправят.
Зачастили что-то. Тут ещё на 5.3 в продакшене не перешли, а уже 5.4.
Неправда, php5.3 давно уже а продакшне.
Смотрим версию на RHEL6: php-5.3.2Так что уже год как перешли.
С RHEL5 ещё никто не переходил, только новые установки если.
у хостеров опять нервно задергался глазик
Что хостеры? Хостеры не будут дергаться и чесаться, пока популярные движки (тот же Вордпресс, ну или Zend для начала) не будут ТРЕБОВАТЬ PHP 5.4. Произойдет это еще эх нескоро (версии фреймворков для 5.3 только на подходе). До этого времени - это будет удел энтузиастов-стартаперов, которые пусть ставят что хотят на своих VDS и дедиках (ну, я и сам такой:) )
Вообще, самой "вкусной" версией должна быть шестая. Ибо там полная поддержка Unicode. Такого пожалуй нигде нет. Но его еще минимум год ждать.
http://www.phpclasses.org/discuss/blog/PHP-Classes-blog/post.../
вот только отложили ее на неопределенный срок, все что планировали в 6 - реализовали в 5.4, кроме юникода разумеется
--------------------------------------от себя добавлю по тестированию sapi fpm-fcgi php5.4-svn (бета в тарболле меня не устроила, т.к. периодически с вордпрессом сегфолтится)
из проблем -
1) несколько модулей Drupal выдали вот такую ошибку в лог -
"Only variables can be passed by reference in" , один модуль исправила, один деинсталлировала ( все равно не нужен никому кроме спамеров )2) APC-3.1.9 выдавал ошибку с double free() при запуске php-fpm, текущий SVN снапшот из PECL такой проблемы не имеет. XCache 1 и EAccelerator по прежнему пока не собираются с 5.4.
из хорошего -
1) По скорости работы вордпресс - работать стало намного быстрее, от времени генерации странички в ~200 мс в новой версии стало ~ 120 мс (это не обещаные 8%, а гораздо больше, сюда же включено и ускорение FastCGI, так что все стало гораздо интереснее)2) потребление памяти - на генерацию страницы теперь идет 3.5 Мб памяти (APC-3.1.9+svn) вместо 4.5 Mb (PHP5.3 + EAccelerator) или 5.5 Mb (PHP5.3 + APC)
значения маленькие в целом, потому что скрипты уже скомпилированы и сохранены в кеше.PS: хоть APC и обещали включить в основной комплект поставки расширений PHP, пока нет его в тарболлах.
кто будет тестировать - удачи.
> "Only variables can be passed by reference in"Давно запланировано. В PHP5.3 честный E_DEPRECATED.
Достаточно удалить амперсанд при _вызове_ функции.
> Ибо там полная поддержка Unicode.Поясните, пожалуйста. Побайтовая проверка UTF-8 и поддержка модификаторов планируется?
К сожалению точного ответа не знаю.
Поясню для интересующихся.1) Каждый символ, кодированный в UTF-8 состоит из идентификатора (по которому определяется количество байт на символ) и хвоста. Если не проверять каждый байт, то при пропуске любого байта (кроме ASCII) часть следующих за ним символов будут неверными — содержать часть соседнего им символа. Согласно стандарту UTF-8 парсер должен пропустить поломанный символ и продолжить корректную обработку остальных.
2) Каждый код Юникода (который не собрать без обработки каждого байта), соответствующий символу UTF-8 следует проверять на нахождение в диапазоне суррогатных пар UTF-16 (убранных в UTF-32), в пределах Юникода, а также проверять чтобы количество используемых символом байт соответствовало нужному (например, ASCII можно закодировать 4-мя байтами). Согласно стандарту UTF-8 парсер должен пропустить такой символ.
3) Символ вместе с модификатором должны считаться парсером за один символ.
perl же
> Ибо там полная поддержка Unicode. Такого пожалуй нигде нет.Полной поддержки юникода нет нигде? А питон как же? В нём изначально поддержка юникода в языке, строки хранятся в UCS-2/UCS-4 и работа с ними безо всяких доп. извращений вроде пхпшного mbstring.
неужели костыль с типа вкорячили ... какой вариант то хоть?
типами
>В $_SERVER['REQUEST_TIME'] теперь передается время с указанием микросекунд;А вот это они какашки.
Все остальное - годно.Вот это тоже важно, на мой взгляд:
><?= is now always available regardless of the short_open_tag setting
func()['key'] - очень радует!
Лучше бы сделали перегрузку операторов, потому что даже нельзя нормально завернуть в класс зоопарк строкових функций
Ну а вот это новшество что пропустили? По-моему оно не менее важное, я его по-крайней мере пару лет ждал
- add short array syntax as defined in https://wiki.php.net/rfc/shortsyntaxforarrays, 2nd solution using => onlyНу т.е. теперь можно будет писать к примеру
func1(["id" => 500, "type" => "account"]);
вместо
func1(array("id" => 500, "type" => "account"));
> Изменено значение по умолчанию для опции "default_charset", вместо ISO-8859-1 теперь указано UTF-8;Ну, наконец-то... В XXI веке давно пора было.