Comments 117
Плюс все современные фреймворки уже поддерживают php7 (laravel, yii, zend, даже частично codeigniter)
Если же вам пришлось переписывать большую часть кода вашего приложения, то боюсь вы не знаете PHP. (сейчас перевел проект с 5.4 на php7, пришлось только несколько deprecated методов поменять)
До выхода PHP7 Symfony говорили — что наша новая версия 3.0, полностью поддерживает PHP7.
Но как? Ведь PHP7 еще не вышел? Просто постарайтесь ответить на этот вопрос и вы возможно все поймете.
http://php.net/manual/ru/errorfunc.constants.php E_DEPRECATED
Дасточно просто включить правильный уровен ошибок и все устаревающие методы вы уберёте задолго до выхода следущей стабильной версии. Ну а вещи вроде $$foo['bar']['baz'] — это гавнокод, которого не должно быть в нормальных проектах.
Сейчас обсуждаются RFC по этому поводу, но почему этого не было сделано в релизе PHP7 — неизвестно.
Я вам больше скажу, в php 7.1 появится еще и тайп хинтинг для свойств объектов (возможно в 7.1) и там так же будет использоваться стиль Си что бы не вызывать затрудений при прочтении в случае использования выражений.
А такого не было?
$bar = isset($foo)? $foo: 'default';
Понимаю хочется прикукрасить, но чтоб настолько…
$bar = $foo ?? $green;
. И потом не всегда понятно от куда $bar = 'red'
когда ожидалось $bar = 'green'
. Как так нет $foo ?????? Ну ок, тогда бери $green.
if(count=test)
for(i=0;i<student.length;i++)
if(student.check) student.show() && student.showGorod() ;
лиш бы не ставить скобки )
Применение рукописных текстов в моей жизни такое, что если я буду писать левой, то мне хватит (если медленно писать, то даже читать можно).
Я вырос на бейсике и асм-z80. Поэтому иногда таки позволяю себе писать без скобок.
Не такой капец конечно, с вложенными циклами и т.п., максимум что я могу наговнокодить это
if($ok) $data = 'qwerty;
else $data = 'uiop';
Но бывает, грешен, каюсь.
Однако не считаю это проблемой — длину метода до 20 строк я соблюдаю более строго, тернарный оператор максимально избегаю (но буду использовать ?? когда перейду на 7, потому что ?? более очевиден).
У Вас есть 40 часов рабочего времени. За это время нужно забутстрапить проект. Сделать Minimum Viable Product для заказчика, чтобы уже работали над функционалом и юзабилити, сделать общую структуру чтобы нужно было запускать мидлов, отдавать архитектуру на ревью, давать пилить ТЗ на подзадачи, строить работу и т.п.
Вопрос:
Код будут смотреть другие люди, код будете смотреть и Вы сами. Чем пожертвуете? Функционалом MVP? Временем на архитектуру? Лично я пожертвую проработкой кода отвечающего за детали. Потеряю пагинации там, граничные случаи и т.п., малозначимыми деталями стиля (например некоторые методы могут вырасти вплоть до 40 строк, периодически встречаться условные структуры как я написал выше и т.п. И да, некоторые такие вещи могут потом пережить даже релиз, если находятся глубоко, в незначительном месте, в принципе читабельны, и проходят тесты....
ради некого дедлайна
У вас почасовая оплата, денег есть на 40 часов вашей работы (потому что это MVP, лишь потыкать идею воплати, что бы понять есть ли смысл вкладывать в нее деньги). Прототип.
Мы с братом в собственной фирме ведем почасовой учет собственного рабочего времени, причем с изменяющейся тарифной сеткой. Эту работу я делаю за 5 баксов, эту за 25, потому что это я мог бы кинуть верстальщику, а это за меня бы делал более дорогой человек, а тут работа стоит 5 баксов, но я считаю ее как за 25, потому что объективных причин не делегировать не было, и мне и так было что делать.
Печалька когда люди не считают собственные ресурсы.
Нет, бывает что задач хватает на 0,25 ставки, но берешь человека в штат потому что так дешевле, или стабильнее, или возможные авралы перекрывают и т.п., и тут можно и по целых 8 часов в день работать если работы на 2 часа. Но это хоть и не редкая ситуация, но частный случай. И если у вас именно так, то это у вас сайд-эффект а не у всех :)
Работа. Причем часто более дорогая чем работа по реализации.
За "всю ночь снилась работа" нужно посылать к невропатологу.
Разовые сайдэффекты сна не вредящие здоровью попадают в статистическую погрешность. Наравне с "отвлекся во время поиска на гитхабе" и тп.
Если же это разумное осознанное и рациональное "думанье", например в очереди/пробке и тп, то почему бы его и не посчитать?
Позавчера снилось что я на ассемблере пишу (с девяностых не писал). Что вцелом логично — неделю кодил до глубокой ночи. А ведь сам же два года назад писал что «штрафовать надо»… эх).
Ну и чтобы два раза не писать. Добавлю — я сейчас перечитал ветку и удивился. Вот я такой умный — про 21-й век и почерк умничал. А утилиты вроде PHP Coding Standards Fixer не использовал. Забавно смотреть на себя спустя всего два года…
У большинства порог "продуктивного" времени — 6 часов в день. Так что если вы не можете решить какую-то задачу за рабочее время — лучше отвлечься и спокойно поспать, дабы с утра свежим взглядом посмотреть на вещи. Как правило люди любят зацикливаться на определенных вариантах и упускают более удобные и правильные решения извиду.
frameworks
и элементарного composer
или же активно пользуеться уже готовыми и от тестироваными решениями. В полне нормальный проэкт и по коду и по качеству с помощью фреймворка и композера, некоторые проэкты ставяться на "адекватные" cms
. Как бы всё давно написанно, и авторизация, и регистрация, и новости не новости, блоги не блоги и т.д. Да и предвкушая вваш ответ, на более менее серьёзные проэкты, выделяеться адекватное время на проэктирование, разработку макета, разработка фронтенд и бэкэнд части, и наращивания функционала.п.с. Строители перед постройкой дома, разрабатывают чертежи, проэктируют комуникацию, и потом только строят начиная с фундамента. А не наоборот.
Но не запускать мидлов и отправлять на ревью архитектуры на базе сляпанного на коленке прототипа. Ей богу, это же ад для команды.
простите господа, всё время забываю как работает человеческий мозг)
Повторюсь:
Я не говорил о том чтобы написать ОпенКарт (как пример говнокода) или Вордпресс с мыслью мол потом доделаем.
Я говорил лишь о том, чтобы позволить себе мелкие шалости вроде написания методов по 30 строк или конструкций вида
if($ok) $data = 'qwerty;
else $data = 'uiop';
(и именно таких, без дальнейших циклов и ветвлений в условиях)
В ответ мне предлагают работать по 16 часов в день и забить на DRY и KISS (может еще и на SOLID забить?) лишь бы не говнокодить.
По дедлайну. 40 часов или 4 часа это без разницы.
Только вот с именами переменных я таки мучаюсь если они живут больше 5 строк.
В меня палкой вбивали что если в коде комментариев меньше чем кода, то лучше бы ты его не писал, а потом когда поменялась идеология, то уже сам осознал, ценой мегабайтов кода в помойку, что сейчас комментарии заменяет простая структура и читабельное именование.
Так что да, могу сделать неформатированный условный блок, но отделю его пустыми строками и обязательно перед коммитом выровняю отступы если вдруг где покосил. Да, $key=>$value в цикле это как за здрасьте, а то и $k=>$v, но только если в пределах экрана… Часто ловлю себя на мысли "скотина, ты 10 минут над именем переменной думаешь, пиши транслитом первое попавшееся и поехали дальше"…
И да, верно именнованный код, который хоть в половину SOLID нечитабельным быть не может.
Хотя знаете… У меня тут разумный вопрос возник. А что, if без скобок, если он однострочный, без приколов со следующим циклом и т.п., с банальным присвоением. Ну пусть даже с таким же else идущим за ним, который встречается в коротком логически понятном методе, это что может хоть немного вызвать неудобство с читабельностью? Я всегда считал, что обязательность скобок в стандарты добавили по той же причине что и запятая у последнего элемента массива — удобство возможных дальнейших правок. За читабельность вообще не задумывался. Не вижу почему конструкция из 5-7 строк будет читабельнее чем из двух… Я не прав? Скажите кому это реально мешает? Может и вправду я не прав и упорствую как упорствовал раньше со своими отступами в 2 пробела...
if (expression == true)
return 'good';
return 'do not good';
В принципе читабельно, а так
if (expression == true)
// return 'good';
return 'do not good';
сломали логику, и не заметили.
Если бы первый ретурн был бы на той же строке, то сломать было бы невозможно.
Ну и тут гремучая смесь нарушений. Два возврата подряд это ад. В сложных структурах, в одном методе несколько return еще можно простить (хотя опять таки какого черта структура сложная?), хотя он и попахивает скрытым goto, но еще можно, но вот так вот в наглую, это хамство.
Ну и если уж про стиль говорите, то константа на втором месте, да еще и == а не === это попахивает гораздо больше чем отсутствие скобок.
Хотя чего это я? В детстве обожал обратную польскую, но сейчас знаю, но никогда-никогда не пишу константу на первом месте. Лень раньше меня родилась)
expression
подразумевалась не константа а какон либо условие… с одной строкой тоже можно накасячить if(expression) return 'good';
return 'not good';
и коментируем
// if(expression) return 'good';
return 'not good';
снова ошибка если предполагалось вернуть пустую строку при expression == true как и в следуещем примере.
if(expression) // return 'good';
return 'not good';
А про сторону условия я имел ввиду то, что рекомендуется писать
if(true === goodWork($work)) {}
а не
if(goodWork($work) === true) {}
А что кто-то пишет сокращенный формат (без скобок) в две строки?
Еще как пишут, например, в yii 1.x оно везде так :)
public function getDriverName()
{
if($this->_driverName!==null)
return $this->_driverName;
elseif(($pos=strpos($this->connectionString,':'))!==false)
return $this->_driverName=strtolower(substr($this->connectionString,0,$pos));
//return $this->getAttribute(PDO::ATTR_DRIVER_NAME);
}
Про комментарии я для себя выработал такую стратегию: вот есть кусок кода, который когда-то кем-то должен поддерживаться. Так вот, мысленно удаляем весь код и оставляем только комментарии. И даём коллеге эти оставшиеся комментарии. Сможет он по этим комментариям восстановить функциональность? Если да, то комментарии необходимые. Не заснёт ли он от скуки, читая килобайты комментариев? Если нет, то комментарии достаточные.
В общем говоря, если надо писать код для машины и только для машины, то какая разница как он будет написан. Если хоть кто-то ещё это будет читать, кроме интерпретатора-компилятора, то я для себя выбрал приоритет такой: сначала — людям, потом — компилятору. И класть я хотел на того, кто мне поставил эти ограничения в 40 часов, нам с ним не по пути.
И ещё момент. Когда я еду на машине, то даже в 4 утра в чистом поле включаю поворотник на развилке условно-дороги. Потому что привычка. И с читабельностью то же самое. Даже если никто не будет читать… привычка уважать.
Только они не должны быть связаны между собой, тогда хоть 100.
От комментариев я отказался когда понял что такое ООП.
Я писал комментарии с детства. В 89-ом написал первую программу. Тогда мне было 9 лет. В 1991-ом выкинул первую программу на 10 страниц, и написал ее с нуля, потому что разбираться со своим же кодом без комментов было дольше. С тех пор начал писать комментарии.
Потом уже в начале нулевых на практике понял что ООП я понимал неправильно, и что каждый маленький кусочек кода должен быть в отдельном методе (или отдельном классе) не потому что так положено там или еще чего, а тупо потому что я так смогу его и только его переопределить в наследнике, сохранив весь остальной код. Так я познал
Но поскольку каждый блок (цикл, ветвление, набор однотипных присвоений и т.п.) я и так выделял комментариями, а мельче комментариев было мало, то комментарии плавно переползли в правильные имена…
Комментарии (если это не комментарий перед методом или свойством, или перед классом) в моем понимании это признание в говнокоде. Если ты спешил, или ради оптимизации пошел на грязный хак или еще чего — напиши комментарий. Если же всё нормально написано, то что он здесь делает?
У меня подход к подобному коду примерно как к обычному коду в учебниках. Хороший чтобы понять идею, но упаси Боже тащить его на прод. Но писать так чтобы выбросить тоже дорого. Если есть приемлимый уровень инкапсуляции, именования и грамотная декомпозиция, то реализацию уже могут за тобой подобьют люди с ценой часа в 2-3 раза ниже. А если у тебя от кода останется только понимание "как нужно", то опять нужно будет скелет делать самому....
Если есть приемлимый уровень инкапсуляции, именования и грамотная декомпозиция, то реализацию уже могут за тобой подобьют люди с ценой часа в 2-3 раза ниже.
И такое видели, правда на выходе обычно получается обычный говкод, сквозь который просматривается некогда изящная идея — печальное зрелище...
А почему нельзя тащить, если сделан качественно?
Нет никаких проблем в "сделано качественно". Есть проблема того что:
- мало кто делает качественно на этом этапе
- делать качественно MVP может быть пустой тратой денег, так как нет гарантии что дальше MVP проект уйдет развиваться. Более того, "качество" влияет на сроки. А на этом этапе чем быстрее — тем лучше. Далее уже, когда мы этот MVP покажем таргет группе какой-нибудь, тогда уже можно принимать решения о том чтобы увеличивать качество.
Причем это абсолютно не значит что мы должны делать MVP на тяп ляп. Если у нас там есть какой-то алгоритм который составляет 90% ценности нашего проекта, на него имеет смысл потратить чуть-чуть больше времени чтобы потом было проще его переносить. А вот делать идеальный UX или сразу расчитывать на большие нагрузки к примеру смысла нет от слова совсем. Конечно бывают ситуации когда UX это и есть 90% ценности приложения, когда у нас есть например продукт-конкурент и мы хотим отжать аудиторию тупо за счет этого. На этом этапе тогда достаточно сделать качественные мокапы/прототипы без всего по сути чтобы уже начать получать фидбэк и конвертировать его в дела.
То есть нужен баланс между качеством и стоимостью. Порой приходится жертвовать качеством что бы быстрее получить реальный фидбэк о том где качества не хватает а не решать выдуманные проблемы.
У некоторых таких проверок бывает больше одной на строку или условие, так что новый оператор определенно повысит читаемость кода в таких случаях.
$foo ??= 'default';
вместо $foo = $foo ?? 'default';
возможно, кстати, и примут (https://wiki.php.net/rfc/null_coalesce_equal_operator).
Удобней, красивее.
А чем она отличается от mt_rand(int $min, int $max)?
http://php.net/manual/ru/function.random-int.php
http://man7.org/linux/man-pages/man2/getrandom.2.html
Полный список разницы тут http://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html
Собственно причина именно в utf8 и байтах и отсутствии implicit конвертации. Все-таки utf8 ввод и чтение это больше как определенный use case, а не парадигма. В 90% случаев мы используем ascii. Большинство протоколов работают только с ними (собственно почему был придуман punycode).
Хотя с программистской точки зрения это верно, с пользовательской точки зрения это лишний геморрой и в дополнение к другим изменениям — просто проблема, которой есть отличное решение — использовать 2.7.
Ждем Py4.
Поэтому PHP7 отличная итерация и слава богу они не пошли путем PHP6 ибо иногда то что с дев. точки зрения верно — с точки зрения пользователя языка неверно.
там нету async await
> Ждем Py4.
но зачем? когда есть на замену достаточно зрелые Go или Kotlin уже сейчас
там нету async await
То что только это заставило всех двигаться на py3, как говорят англичане, "speaks volumes".
но зачем? когда есть на замену достаточно зрелые Go или Kotlin уже сейчас
У Go куча своих проблем, по-мимо кривого синтаксиса (уж лучше писать на cython тогда), Kotlin, как вижу, все тот же брекетный синтаксис.
Все что Питону не хватает на самом деле (и что задержало его захват мира) это GIL. Избавиться от него и Питон бы стал мега популярным (ибо использовать multiprocessing для полноценного тредирования это верх дебилизма).
Да и на одно правильное использование придется куча замаскированных таким образом instanceof, что свидетельствует об архитектурных проблемах.
Уж лучше методы добавить.
В языке с динамической типизацией это только создаст проблемы
Если есть полноценная поддержка типов (а она уже есть), то оно логично и не создает проблем если работает детерминировано (а можно даже
declare(strict_types=1);
заюзать)Да и на одно правильное использование придется куча замаскированных таким образом instanceof, что свидетельствует об архитектурных проблемах.
Но это не проблема языка. Только что кстати топик был про создание дат и извращения с
static function
— вот там перегрузка конструктора была бы очень к месту.А еще было бы здорово видеть перегрузку операторов, оно конечно довольно редко нужно, но тем не менее...
Перегрузка операторов — такая штука… Ей злоупотребить не легко, а очень легко. Вспоминается единственный пример (кроме очевидных с какими-нибудь комплексными числами), где это уместно — SQLAlchemy, там красиво получилось.
Хотя я в свое время истерил по поводу возвращения goto. Но ничего не произошло. Кто говнокодил, говнокодит и дальше, кто писал нормально, пишет и дальше. И ни разу не встретил goto ни там ни там))
Привычный плюс неприменим потому что нестрогая динамическая типизация. И дальше по цепочке.
Уродство с функциями от быстрой разработки, чтобы всё и сразу заработало — тянули готовые библиотеки не сильно зоботясь о приведении к единому виду.
Быстрый выход на широкий функционал и всяческие упрощения типа динамической типизации это основа популярности пыха. Не было бы этих проблем, не было бы языка. Так бы и остался нишевым шаблонизатором)
Привычный плюс неприменим потому что нестрогая динамическая типизация.
Скажите это JavaScript-у :)
Быстрый выход на широкий функционал
Он просто занял свободную нишу — не было тогда ничего специально для веб-а.
Впрочем в общем выводе ничего не меняется — проще парсер, быстрее в продакшн.
А на счет "просто занял свободную нишу" та это можно сказать про 90% крупных компаний и брендов.
Они "просто" заняли.
Меж тем потрать они в пять раз больше времени и сил на более качественный продукт, и они бы "свободную нишу" не заняли бы. Потому что она была бы уже занята, и им пришлось бы конкурировать с тем кто был бы там уже....
Я скорее имел ввиду проблемы с понятностью такого кода.
Обычно какой то определенный тип всё равно неявно подразумевается, а как он выглядит "123" или 123 дело десятое. Даже в чужом древнем говнокоде времен php 5.3 состоящем из "функций+псевдо ооп+зачатки ооп" я не вижу анархии типов. И в js её тоже нет. Поэтому думаю что когда везде будут использоваться типы то и проблем или не будет или их будет не так много как вам кажется :)
Перегрузка операторов — такая штука…
Смотрю на портянки вызовов
bc*
и плачу...C bcmath/gmp — очевидно нужно, на уровне php extensions такую поддержку сделать бы неплохо. А в userland — ну не знаю, не знаю, в С++ этим очень часто злоупотребляют.
- (только мое мнение) Named Parameters на функциях с маленьким числом параметров не нужно, функции с большим их количеством — говногод. А еще очень глупо привязываться в своем коде к внутренним названиям параметров — это целая кучка радости после того как автор библиотеки её немного отрефакторит :)
- Не только или по вашему вот это читабельнее чем несколько методов?
public function addItems($items) {
$result = false;
if (is_string($items)) {
list($itemId, $itemCount) = explode(':', (string) $items) + array(0, 1);
$result = $this->addItem($itemId, $itemCount);
} elseif (is_int($items)) {
$result = $this->addItem($items);
} elseif (is_array($items)) {
if (isset($items['item_id'])) {
$result = $this->addItem($items['item_id'], $items['item_count']);
} else {
foreach ($items as $item) {
if (!$this->addItems($item)) {
$result = false;
break;
}
}
}
} elseif ($items instanceof Collection) {
foreach ($items->getItems() as $item) {
if (!$this->addItems($item)) {
$result = false;
break;
}
}
} elseif ($items instanceof MemberItem) {
$result = $this->addItems($items->item);
} elseif ($items instanceof X) {
// и тут еще кучка разных поддерживаемых классов
} else {
throw new Exception();
}
return $result;
}
assertEqual($actual, $expected, delta => 0.0001);
пока же приходится писать так:
assertEqual($actual, $expected, '', 0.0001);
Согласитень, первый вараинт намного проще "читать". А читабельность и выразительность кода намного важнее.
По поводу Ad-hoc полиморфизма — он не нужен в виде перегрузки методов а больше для операторов. В вашем коде с добавлением возможности "перегружать" методы, мы по сути просто ифы вынесли в чуть другие конструкции языка. В итоге у нас появляются методы объекта, делающие одно и то же но с разными сигнатурами что сильно усложняет интерфейс, и раздувает код, который его использует.
Вместо этого лучше воспользоваться параметрическим полиморфизмом, пример которого вы собственно и привели. А еще лучше — полиморфизм подтипов.
А читабельность и выразительность кода намного важнее
Магические числа — зло :) А с какой нибудь говорящей константой/переменной/настройкой разница уже небольшая.
В итоге у нас появляются методы объекта, делающие одно и то же но с разными сигнатурами что сильно усложняет интерфейс
Кучка методов гораздо читабельнее чем аналогичная портянка if-ов + чаще они делают не одно и тоже, а просто выполняют конвертацию к типам которые нужны оригинальному методу.
и раздувает код, который его использует.
Не совсем понятно почему — в вызывающем коде у нас в любом случае есть единственный метод
addItems
.Магические числа — зло :)
Это не магическое число, и для каких-то тестов нужна дельта в
0.0001
а где-то 0.01
. Делать на каждый случай константу — не очень разумно с точки зрения поддерживаемости. Ну и опять же — это больше как кастыль а не решение проблемы. С именованными параметрами — это без проблем решается.Кучка методов гораздо читабельнее чем аналогичная портянка if-ов
Вот только ифы мы не видим, как пользователи этого кода. Мы видим только метод, который делает то, что нам нужно.
в вызывающем коде у нас в любом случае есть единственный метод addItems.
Раз уж у нас в этом методе появилась куча if-в, значит либо у нас нарушен принцип единой ответственности, либо мы не воспользовались полиморфизмом подтипов, либо просто мы не правильно написали код. Мне об этом говорят:
куча else if-ов, отсутствие аргумента $itemCount у метода, проверки на instanceof.
Это не магическое число, и для каких-то тестов нужна дельта в 0.0001 а где-то 0.01
Неразумно как раз таки разбросать эти числа по всем тестам и потом страдать вспоминая что это и почему оно здесь именно 0.01, а не 0.0001, а может вообще 0.1 надо? :) Если не нравятся константы/переменные/настройки — можно добавить какой нибудь
assertEqualFloat()
.Вот только ифы мы не видим, как пользователи этого кода. Мы видим только метод, который делает то, что нам нужно.
При перегрузке кучу методов мы тоже не видим — они есть только внутри нашего класса, и по сути мы просто перекладываем логику нашего
if
на плечи интерпретатора (что в сложных случаях даже сокращает количество методов).Раз уж у нас в этом методе появилась куча if-в, значит либо у нас нарушен принцип единой ответственности, либо мы не воспользовались полиморфизмом подтипов
Ну… альтернатива тут добавить методы типа
addItem()
, addItemFromMemberItem()
и т.д. и использовать их, вот только это как раз ведет к усложнению интерфейса и в сложных системах размазывает нашу изначальную простыню по всему проекту — это еще хуже.Мне об этом говорят:
Просто код немного утрирован :) в реальности там не все так страшно.
if
запросто может потянуть на 2-3 десятка строк сложной логики, которую придется вынести в отдельные методы… и… на выходе получить тот же самый раздутый код, но только с одним дополнительным if
-ом. А между тем работу этого блока спокойно мог бы выполнять интерпретатор...Не очень это хорошо, имхо.
Что же в этом плохого? Просто не надо как на Java многие писать и все будет хорошо (я про шутку с фабрикой проблем). Объектную модель PHP слизал с java еще лет 10 назад, так что уж теперь удивляться.
Использовать freetds и odbc в этом проекте на этих новых вэбах не могу…
php7.0-sybase - Sybase module for PHP
это расширение?Сейчас в исходниках исчезли пакеты для компиляции этого модуля. Раньше были здесь — /ext/sybase_ct
Пробовал брать их от ветки 5.6 — непомогло, появляются ошибки
Мне же нужны исходники для компиляции самой PHP с поддержкой sybase-ct
Мне достался legacy проект на Drupal 5 и CodeIgniter 3, который потребовалось перетащить на PHP 7. Да, в 2020-м.
Как же мне вот этот сахар поломал проект и сколько часов я грохнул на то, чтобы это отловить!!!
$foo->$bar['baz'] был $foo->{$bar['baz']} стал ($foo->$bar)['baz']
20 файлов с этой конструкцией… жаль, нельзя просто отключить в настройках!
Уважаемый hDrummer, несказанно благодарен вам за эту статью!
Введение в PHP 7: Что добавлено, что убрано