Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 91
Хостеров, не желающих обновлять php5, можно понять. А как им еще быть, если функцию php.net/htmlspecialchars в 5.4 сломали, да так, что починили только в 5.6? На минуточку: если сайт сделан не в кодировке utf-8, а в однобайтной, то все существующие в нем вызовы htmlspecialchars в 5.4 и 5.5 начинают возвращать пустоту, если в строке есть хотя бы один байт с кодом 128+ (например, с русскими буквами). Думается, у хостеров однобайтных сайтов должно быть довольно много: кто еще пользуется их услугами, как не олдскульные юзеры…
Наверное, ни одно другое действие не способствовало процветанию utf8 так сильно, как этот вопрющий баг. Впрочем, карму php оно тоже попортило знатно.
Наверное, ни одно другое действие не способствовало процветанию utf8 так сильно, как этот вопрющий баг. Впрочем, карму php оно тоже попортило знатно.
А в чем проблема то в обновлениях хостерам? Какая им разница что там где сломали в php?
У меня на виртальном версии от 5.2 до 5.6. И неделю назад объявили об отказе о поддержке 5.2
У меня на виртальном версии от 5.2 до 5.6. И неделю назад объявили об отказе о поддержке 5.2
Проблема в клиентах, у которых после обновления PHP перестают работать некоторые скрипты, и они далеко не всегда сразу понимают, почему и как это исправить.
Подождите, вы меняете сами версию php. Кто и где сейчас из хостеров принудительно менят php юзеру. Да в 5.4 сломали, ну 5.4 случайно не накатить. Причинно следственные связи ж налицо.
Как-то я случайно поменял с 5.4 на 5.6… при очень неосторожном обновлении Debian. Хоть и не хостер, но разработчики на проекте ругались долго.
в этом случае вы как раз хостер, который случайно обновил php. Скажите пацанам чтоб не выпендривались
php.net/supported-versions.php
С 1 января этого года версия 5.4 получает только секъюрные апдейты. с 2016 перестает делать и это.
Сколько там функций то переписать времени нужно под 5.6? Не говна ли больше и головняка уже не будет:-)
Версия 5.6 явно работает быстрее, я сужу по времени генерации страниц. Есть опкеш и т.п
Я конечно не знаю всей вашей ситуации.
php.net/supported-versions.php
С 1 января этого года версия 5.4 получает только секъюрные апдейты. с 2016 перестает делать и это.
Сколько там функций то переписать времени нужно под 5.6? Не говна ли больше и головняка уже не будет:-)
Версия 5.6 явно работает быстрее, я сужу по времени генерации страниц. Есть опкеш и т.п
Я конечно не знаю всей вашей ситуации.
… я забыл добавить про htmlspecialchars(), что в 5.4 и 5.5 не существует решения этой проблемы, кроме как замена ВСЕХ htmlspecialchars на myhtmlspecialchars, и уже в функции myhtmlspecialchars() пробивать кодировку, отличную от utf8. А т.к. в большинстве старых скриптов вызовы htmlspecialchars() встречаются сотнями, это очень серьезный масштаб разрушений. Конфигурируемое через ini_set() дефолтное значение кодировки появилось только в 5.6.
Полностью с тобой согласен, некоторые индусские разработчики PHP плевать хотели на обратную совместимость.
А некоторых за описание этого бага даже минусовали ( habrahabr.ru/post/137296/#comment_4572064 )
А некоторых за описание этого бага даже минусовали ( habrahabr.ru/post/137296/#comment_4572064 )
> PHP7 находится на одном уровне с HHVM
> PHP7 не имеет JIT-компилятора
М-мм… Вообще не на том же он уровне находится.
А самым ожидаемым будет скалярный тайп-хинт, конечно.
> PHP7 не имеет JIT-компилятора
М-мм… Вообще не на том же он уровне находится.
А самым ожидаемым будет скалярный тайп-хинт, конечно.
Дим, тут имеется ввиду производительность, по всей видимости (такие тесты есть в интернете). По возможностям HHVM далеко опережает PHP7, по крайней мере пока, но «семёрка» — огромный шаг вперёд, шажище.
А самым ожидаемым будет скалярный тайп-хинт, конечно.Возможно. Хотя у него масса недостатков, к сожалению, например, нельзя указать array|\ArrayObject или float|int.
Ещё непонятен момент с null. Если моя функция принимает или возвращает null|bool, например?
Ну, это-то как раз просто. Уже сейчас можно, например, писать так:
function test(callable $func = null) {
// …
}
в идеале не должно быть таких функций. функция должна возвращать только один тип данных и кидать exception в случае какого-то сбоя. прошу прощения, что не ответил на ваш вопрос — самому интересно :)
>> функция должна возвращать только один тип данных
Не согласен. Вам в БД же не выскакивает ошибка, когда вы вставляете в поле с foreign key значение null. Null — это такое значение, которое возможно в любом наборе данных.
Не согласен. Вам в БД же не выскакивает ошибка, когда вы вставляете в поле с foreign key значение null. Null — это такое значение, которое возможно в любом наборе данных.
в идеале не должно быть таких функций. функция должна возвращать только один тип данных и кидать exception в случае какого-то сбоя. прошу прощения, что не ответил на ваш вопрос — самому интересно :)
Ну не знаю. Вот примеры:
1. Поиск элемента в массиве. Если найден — возвращается элемент, если не найден — null
2. Получение ошибки валидации данных.
getError() возвращает ошибку если она есть и null если нету.Использовать exception в таких случаях — использование их не по назначению, как по мне.
а что если существует элемент со значением null?
вообще довольно распространенной практикой поиска элемента в массиве является получение индекса искомого элемента в массиве (indexOf) и значение -1 если такового элемента не было найдено. тот же array_search возвращает FALSE в случае если элемента не найден, что позволяет однозначно идентифицировать тот факт, что элемент не найлен
вообще довольно распространенной практикой поиска элемента в массиве является получение индекса искомого элемента в массиве (indexOf) и значение -1 если такового элемента не было найдено. тот же array_search возвращает FALSE в случае если элемента не найден, что позволяет однозначно идентифицировать тот факт, что элемент не найлен
а что если существует элемент со значением null?
Ну и ок. Для моей идеи такое поведение подходит. Допустим, у нас есть список студентов. Мы хотим найти студента с именем «Потапенко Андрей»:
students.searchBy( 'name', 'Potapenko Andrew' )
В стандартном поиске indexOf передается сам объект, потому нету смысла его возвращать. Я говорю именно про поиск неизвестного объекта, который подходит под шаблон. К примеру игра на C#:
var ability = unit.FindAbility<AttackAbility>();
if (ability == null) {
ShowAlert( CANT_ATTACK );
} else {
ability.activate();
}
array|\ArrayObject
И хорошо что не могут. По идее ArrayObject должен подпадать под array, то что сейчас это не так это отдельная история. В любом случае массивы это не скаляры и такое поведение было уже давно, а RFC с тайп хинтингом для скаляров не призвано было пофиксить проблемы с уже существующими вещами. А float|int вообще не имеет никакого смысла. float норм, покрывает собой int. Значит только его и юзать. Сама идея объединения типов нарушает идею тайп хинтинга.
По идее ArrayObject должен подпадать под array, то что сейчас это не так это отдельная история.По идее array должен попадать под \Iterable, но не попадает, примитивный тип, отдельная история, да.
А float|int вообще не имеет никакого смысла. float норм, покрывает собой int. Значит только его и юзать. Сама идея объединения типов нарушает идею тайп хинтинга.Да, float|int бесполезно, признаю́. Объединение типов полезно было бы на стыке примитивов и ООП.
По идее ArrayObject должен подпадать под array, то что сейчас это не так это отдельная история
Скорее, они оба должны попадать под какой-либо ArrayLike или IIterable.
А тупо падать в бесконечной рекурсии разучится, говорить-то начнет чего-нить?
Да.
bolk@MacBook-Pro ~$ /opt/php-7.0a/bin/php -r '$a = function() use(&$a) { $a();}; $a();'
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in Command line code on line 1
$obj->$properties['name'] проинтерпретировал сначала как $obj->properties['name'] (без знака доллара у properties) и долго не мог вкурить, о чем это автор говорит =)
class foo { static $bar = 'baz'; }
class baz { static $bat = 'Hello World'; }
baz::$bat = function () { echo "Hello World"; };
$foo = 'foo';
($foo::$bar::$bat)();
Только мне подобное внушает ужас?
Ну, это наверное потому что это PHP ;)
на самом деле, можно очень много чего такого придумать, что потом разработчик будет один час на 5 строчках голову ломать, и при этом, код вроде нормальный ;)
на самом деле, можно очень много чего такого придумать, что потом разработчик будет один час на 5 строчках голову ломать, и при этом, код вроде нормальный ;)
Ну, мне не внушает. Вы в других языках подобное не видели что ли?
Видел, они меня тоже вгоняют в уныние.
Побочные эффекты могут быть просто невероятны и невероятно сложны в отладке.
Побочные эффекты могут быть просто невероятны и невероятно сложны в отладке.
ОМГ. Обычная штука, ничего странного, какие ещё побочные эффекты? Просто в ПХП это раньше не работало, теперь работает.
Это ведь не продакшн код, а демонстрация возможностей языка. Никто и не говорит, что такое нужно использовать в продакшене.
Если уж на то пошло, то сложность этого кода зависит от понимания разработчиками. Если все понимают и все покрыто тестами — отличный код для продакшена.
вы в С++ variadic templates юзали и их предшественников из Boost, смотрели в код? Там же чёрт ногу сломит, понять сложно написанное. То же самое и про PHP: кто знает и способен юзать, тот будет. А пользователям классов и API не обязательно лазить по внутренностям.
Мы ведь вообще не об этом сейчас говорим. Мы говорим о том, что какова бы ни была сложность кода, если он предназначен для демонстрации изменений, которые были произведены в языке, она не имеет значения. Потому что читать и поддерживать этот код никто не будет. Он — просто иллюстрация.
Совершенно неважно что это за код и откуда, если он просто иллюстрирует возможности языка
Совершенно неважно что это за код и откуда, если он просто иллюстрирует возможности языка
Я помню когда только появился php5 многие хостинги ухищрялись и ставили по 2 версии php, старый код с расширением .php обрабатывался 4 версией интерпретатора, а новый с расширением .php5 уже 5 версией.
Тогда совместимость не ломалась, а разница между 4 и 5 версиями была не столь велика как например между php 5.2 и php 5.6.
Тогда совместимость не ломалась, а разница между 4 и 5 версиями была не столь велика как например между php 5.2 и php 5.6.
сейчас наблюдается переломный момент в плане обновления спецификаций, но сообщество как-то неоднозначно воспринимает их: если выхода ES6 ждут и пилят фичи, которые позволяют использовать сырой ES6 уже сейчас чтобы было легче перейти потом, то python3 и php7 либо дружно отвергают, либо не знают что будет
дело в том, что предыдущих версиях ES все было сыро, а в ES6 будет круче? возможно, но тогда не могу согласиться с тем, что в актуальных версиях Python и PHP все отлично. наверное, дело не в этом
а может разработчики пошли не тем путем, которого ожидало сообщество? а каким путем следовало пойти?
дело в том, что предыдущих версиях ES все было сыро, а в ES6 будет круче? возможно, но тогда не могу согласиться с тем, что в актуальных версиях Python и PHP все отлично. наверное, дело не в этом
а может разработчики пошли не тем путем, которого ожидало сообщество? а каким путем следовало пойти?
обычно если изменяется мажорный номер версии, то можно не говорить об обратной совместимости. да, код php4 может частично работать под php5 в виду того, что некоторые ф-ии поддерживаются, но они уже deprecated. аналогичную ситуацию следует ожидать и php5->php7. некоторые так пишут проекты, что даже в одной мажорной версии проект может не работать, но это зависит уже от разработчика. у меня крутится один такое проект, который работает только на php5.3 и для него приходится держать отдельный сервер чтобы не городить костылей с мультиверсионностью
да, брать бету можно будет, но вот стоит ли уже писать на ней новые проекты? сомневаюсь. я бы не рисковал. к тому же неслепой заказчик не всегда согласится на передовые версии ПО, а скорее всего будет склоняться к более стабильной версии. и именно из-за этого и будет замедляться переход на новую версию
вот поиграться и покатать бету можно будет — это будет интересно
аналогичная ситуация с ES6 — зоопарк браузеров все еще развивается и разрастается и не все обновляют свои «клиенты». снова нужно ждать пока появится лучшая поддержка стандарта браузерами
в любом случае прогресс — это отлично!
да, брать бету можно будет, но вот стоит ли уже писать на ней новые проекты? сомневаюсь. я бы не рисковал. к тому же неслепой заказчик не всегда согласится на передовые версии ПО, а скорее всего будет склоняться к более стабильной версии. и именно из-за этого и будет замедляться переход на новую версию
вот поиграться и покатать бету можно будет — это будет интересно
аналогичная ситуация с ES6 — зоопарк браузеров все еще развивается и разрастается и не все обновляют свои «клиенты». снова нужно ждать пока появится лучшая поддержка стандарта браузерами
в любом случае прогресс — это отлично!
для того, чтобы запускать тесты нужно, как минимум, чтобы код был тестируемым. в упомянутом проекте код нетестируем и достался от немцев-рукоблудников. что говорить, если «смешались в кучу кони, люди» — php+html. как раз та ситуация, что работает — не трожь
да, все верно, если есть написанные тесты, то можно быстро локализировать проблему
заказчику нужен продукт, но, во-первых, бывают разные заказчики; во-вторых, мне самому сейчас не хочется начинать писать проект на php7. пройдет немного времени, все устаканится — можно будет смело писать
только на хостингах все равно останется php5.4-5.6 и php7 в роли экзотики
да, все верно, если есть написанные тесты, то можно быстро локализировать проблему
заказчику нужен продукт, но, во-первых, бывают разные заказчики; во-вторых, мне самому сейчас не хочется начинать писать проект на php7. пройдет немного времени, все устаканится — можно будет смело писать
Она станет стабильной осенью. А минимальной полностью поддерживаемой версией станет 5.6.
только на хостингах все равно останется php5.4-5.6 и php7 в роли экзотики
Теперь я знаю, что говорить в ответ на вопрос «что такое php»: AST появилось в седьмой версии.
Приятно видеть, что даже в языках, всю историю кичившихся своей динамической типизацией, стали постепенно внедрять проверку типов на этапе компиляции. Жалко только, что это опять полумеры — раз уж все равно обратную совместимость сломали, можно было бы сделать более серьезную систему типов, например как предлагают в комментарии выше.
1. Обратную совместимость не сломали.
2. Динамическая типизация никуда не делась, переменные все так же могут принимать любой тип.
ИМХО, выгода PHP больше в скорости, интерпретируемости, и большой встроенной web-ориентированной библиотеке. Именно поэтому уже давно внедрены и классы и типы и т.д. Т.е. никто не держался никогда за отсутствие типов.
2. Динамическая типизация никуда не делась, переменные все так же могут принимать любой тип.
ИМХО, выгода PHP больше в скорости, интерпретируемости, и большой встроенной web-ориентированной библиотеке. Именно поэтому уже давно внедрены и классы и типы и т.д. Т.е. никто не держался никогда за отсутствие типов.
- В статье перечислено несколько древних вещей, которые были выпилены из новой версии, и как минимум одна конструкция, которая, что еще хуже, теперь работает по-другому. Согласен, что эти изменения затронут немногих пользователей, но в моем понимании обратная совместимость либо полная, либо частично сломана.
- Я и не говорил, что кто-то отказывается от динамической типизации. Я сказал, что возможность добавить дополнительные проверки типов для тех, кто считает их необходимыми — это хорошо.
Нет будет там проверки на этапе компиляции. Тайпхинтинг — не про это. Фактически, это сахар для
Т.е. то, что и нужно было давно вводить после тайпхинтинга классов. Про двойные типа да, жаль (хотя, тайпхинтинг, наоборот, должен применяться для повышения градуса строгости и уменьшения полиморфизма функций). Деструктуризации, как в ES6, тоже не предвидится, и это тоже жаль.
function sendHttpStatus(int $statusCode, string $message) {
header('HTTP/1.0 ' .$statusCode. ' ' .$message);
}
//non-strict
function sendHttpStatus($statusCode, $message) {
$statusCode = (int) $statusCode;
$message = (string) $message;
header('HTTP/1.0 ' .$statusCode. ' ' .$message);
}
//strict
//declare(strict_types=1);
function sendHttpStatus($statusCode, $message) {
if (!is_int($statusCode)) {
throw new InvalidArguments();
}
if (!is_string($message)) {
throw new InvalidArguments();
}
header('HTTP/1.0 ' .$statusCode. ' ' .$message);
}
Т.е. то, что и нужно было давно вводить после тайпхинтинга классов. Про двойные типа да, жаль (хотя, тайпхинтинг, наоборот, должен применяться для повышения градуса строгости и уменьшения полиморфизма функций). Деструктуризации, как в ES6, тоже не предвидится, и это тоже жаль.
Фича действительно получается недоделанной. Во-первых, все проверки все равно проходят в рантайме и пока функцию никто не вызвал, невозможно узнать, что она написана или используется неправильно.
Во-вторых, двойные типы не уменьшают градус строгости типизации, а скорее более естественным образом описывают существующую стандартную библиотеку. В текущем варианте для функции, принимающей
Во-вторых, двойные типы не уменьшают градус строгости типизации, а скорее более естественным образом описывают существующую стандартную библиотеку. В текущем варианте для функции, принимающей
int или float, придется отказаться от тайпхинта вообще, что явно менее строго, чем int|float.Во-первых, все проверки все равно проходят в рантайме и пока функцию никто не вызвал, невозможно узнать, что она написана или используется неправильно.
Это не так. В PHP нет компиляции, поэтому единственный, кто может указать на неправильный вызов функции — IDE. Так она и отлично укажет.
Фича действительно получается недоделанной. Во-первых, все проверки все равно проходят в рантайме и пока функцию никто не вызвал, невозможно узнать, что она написана или используется неправильно.
Это верно. Возможно, это должно нас всех стимулировать к написанию юнит-тестов по поводу и без :)
PHP RFC: Remove deprecated functionality in PHP 7
ext/mysql (since PHP 5.5; use ext/mysqli or ext/pdo_mysql instead) REMOVED (PECL extension)
Мне кажется, что только из-за удаления (переноса в PECL) mysql процесс миграции у хостинг-провайдеров может затянуться надолго. Количество кода, использующего старый mysql ext непропорционально велико.
ext/mysql (since PHP 5.5; use ext/mysqli or ext/pdo_mysql instead) REMOVED (PECL extension)
Мне кажется, что только из-за удаления (переноса в PECL) mysql процесс миграции у хостинг-провайдеров может затянуться надолго. Количество кода, использующего старый mysql ext непропорционально велико.
По идее, достаточно скомпилировать соовтетствующее расширение как PECL-модуль, залить в нужный каталог и прописать в php.ini (на shared хостинге или на виртуальном сервере по умолчанию).
Зачем PECL-модуль, достаточно просто интерфейс к mysqli на PHP написать.
Хостер, может, и напишет. А его клиентам это не факт, что надо.
Так ведь и я о том же.
Теперь понял. Но, по идее, модуль на C должен работать побыстрее, чем дополнительный интерфейс к другому расширению.
По-моему, клиентов шаред-хостингов скорость особо не волнует.
Зато хостера волнует, сколько клиентских сайтов можно разместить на одном сервере, чтобы клиенты на тормоза и нехватку памяти не жаловались.
И для этого вы хотите загружать в каждый процесс PHP еще одно бесполезное расширение…
Всё быстрее скомпиленное расширение (тем более не бесполезное, а используемое большинством клиентов) загрузить, чем при каждом открытии страницы интерпретировать такой же кусок на PHP.
чем при каждом открытии страницы интерпретировать такой же кусок на PHP.
Вы видимо не поняли, что такое интерфейс к mysqli. Но это не переписывание библиотеки на PHP.
Это, образно говоря:
function mysql_query($query, $link){
return mysqli_query($link, $query);
}
А всё равно интерпретатору при вызове скрипта (не важно, надо это или нет) придётся разбирать этот код. Он же принудительно включается через php.ini?
(тем более не бесполезное, а используемое большинством клиентов)
Бесполезное тем, что mysqli то тоже будет грузиться.
А всё равно интерпретатору при вызове скрипта (не важно, надо это или нет) придётся разбирать этот код.
Да, только разница между несколькими функциями-обертками и полноценной библиотекой очевидна.
У меня есть вопрос по поводу производительности массивов в PHP и HHVM. Они стали быстрее в PHP7, и при этом они очень медленные в HHVM, где не вижу ускорения работы с ними, и к тому же они почему-то потребляют в 3 раза больше памяти по сравнению с тестовыми сборками PHP7.
Spl так вообще в раз в 10 медленнее в HHVM по сравнению с обычными массивами и не показывают уменьшение памяти.
Вот ссылка на мой бенчмарк 3v4l.org/8QZcN, по мотивам которого видимо можно написать целую статью о мифах и легендах. Например:
— в последнем HHVM 3.6.0 доступ к массиву с числовым ключом, заданному через константу define, по прежнему медленее, чем доступ по числу, но быстрее чем по «string». Хвалёный компилятор не может константы define полностью приравнять к числам? В предыдущих hhvm, особенно 3.5.1 так вообще быле регрессия, define было в 2 раза медленнее «string».
— аналогично в ночных сборках php7, define быстрее “string” но медленнее integer. Не зря существуют отдельные расширения для PHP, которые ускоряют константы. Когда же это появится в PHP из коробки?
— php7 в этом тесте на массивах в 2 раза быстрее HHVM 3.6.0 на “string” и define, и в 1.5 раза на числовых индексах. У hhvm 3.6.0 наблюдается регрессия в скорости массивов почти в 2 раза по сравнению с предыдущими версиями.
— spl в php 5.6.7 не быстрее define и integer, только лишь немного лучше по памяти до 25%
— во всех версиях php ниже 5.6 доступ к массиву по константе define медленнее даже “string”
Почему ни в PHP, ни в HHVM никак не сделают быстрые define? Почему до сих пор существуют костыли в виде apc_define_constants, hidef?
Spl так вообще в раз в 10 медленнее в HHVM по сравнению с обычными массивами и не показывают уменьшение памяти.
Вот ссылка на мой бенчмарк 3v4l.org/8QZcN, по мотивам которого видимо можно написать целую статью о мифах и легендах. Например:
— в последнем HHVM 3.6.0 доступ к массиву с числовым ключом, заданному через константу define, по прежнему медленее, чем доступ по числу, но быстрее чем по «string». Хвалёный компилятор не может константы define полностью приравнять к числам? В предыдущих hhvm, особенно 3.5.1 так вообще быле регрессия, define было в 2 раза медленнее «string».
— аналогично в ночных сборках php7, define быстрее “string” но медленнее integer. Не зря существуют отдельные расширения для PHP, которые ускоряют константы. Когда же это появится в PHP из коробки?
— php7 в этом тесте на массивах в 2 раза быстрее HHVM 3.6.0 на “string” и define, и в 1.5 раза на числовых индексах. У hhvm 3.6.0 наблюдается регрессия в скорости массивов почти в 2 раза по сравнению с предыдущими версиями.
— spl в php 5.6.7 не быстрее define и integer, только лишь немного лучше по памяти до 25%
— во всех версиях php ниже 5.6 доступ к массиву по константе define медленнее даже “string”
Почему ни в PHP, ни в HHVM никак не сделают быстрые define? Почему до сих пор существуют костыли в виде apc_define_constants, hidef?
действительно у HHVM проблемы с массивами :)
http://3v4l.org/50UMD/perf#tabs
Надо бы протестировать kPHP и сравнить результат
ЗЫ, цель кода была усложнить вычисления
http://3v4l.org/50UMD/perf#tabs
Надо бы протестировать kPHP и сравнить результат
ЗЫ, цель кода была усложнить вычисления
Попробуйте объявлять константы через const, а не define.
Ребят решил выучить php, что можете подсказать?
Здравствуйте
Подскажите, пожалуйста, для чего здесь первая пара скобок?
Изучаю php, но такого не встречал.
{} — управляют порядком вычисления?
{$obj->$properties}['name'] — здесь не нужен $ перед фигурной скобкой?
Подскажите, пожалуйста, для чего здесь первая пара скобок?
($foo::$bar::$bat)();
Изучаю php, но такого не встречал.
{} — управляют порядком вычисления?
{$obj->$properties}['name'] — здесь не нужен $ перед фигурной скобкой?
Подскажите, пожалуйста, для чего здесь первая пара скобок?
($foo::$bar::$bat)();
Управляет приоритетом исполнения, также как и
(2+2)*4. Сначала получаем значение статической переменной $bat из класса baz, а т.к. она является анонимной функцией, то тут же ее и исполняем. Можно было бы сделать и так:$qux = $foo::$bar::$bat;
$qux();
Продробнее можно прочитать тут и тут
{} — управляют порядком вычисления?
{$obj->$properties}['name'] — здесь не нужен $ перед фигурной скобкой?
Фигурные скобки используются в PHP для определения границ именования переменной в строках и при использовании переменных переменных
У нас в ihc.ru уже можно пробовать :) http://php7.for-test-only.ru/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чего ждать, когда ждешь ребенка: PHP 7, часть 1