Comments 25
function inc(&$num) { $num++; }
$i = 0;
inc(&$i);
var_dump($i); // int(1)
семантика отличалась. До php 5.4 вы таким образом передавали явно ссылку. Причем даже если функция собиралась по значению работать, так же можно было ссылку передать. Сейчас вы получите ошибку "call-time pass-by-reference". Предлагаю чуть поменять семантику — что бы указание на стороне вызывающего явной ссылки никак не влияло на рантайм и только на читабельность.
Да, формально семантика отличалась, но фактически вменяемые разработчики использовали именно так, как предлагается в нынешнем RFC. Когда вышел 5.4, я сильно недоумевал такому решению и, матерясь, вычищал амперсанды в вызовах по всему коду (благо, такого было немного).
As a simple example, consider the following two calls, which look deceptively similar:
$ret = array_slice($array, 0, 3); $ret = array_splice($array, 0, 3);
По мне это лучше, чем deceptively different
$ret = array_splice($array, 0, 3);
$ret = array_splice(&$array, 0, 3);
еще один вид комментириев?
скорее опциональную возможность визуально отмечать как была передана переменная. По ссылке или по значению. То есть на рантайм это никак не повлияет, и если функция не принимала ссылки волшебным образом, как это было до 5.4 то добавление этой метки выкинет ошибку.
если функция принимает аргумент не по ссылке, то на такой код должно ругнуться.
доп. защита от описок.
Показывает, что переменная передаётся по ссылке. Явное лучше неявного и всё такое.
Не могу понять зачем ввели тип object
. Все равно когда нам нужно, гарантировать определенное поведение объекта мы делаем тайпхинт через интерфейс. А что по сути начит object — хоть что лишь бы не скаляр, массив, null и ресурс. Какое может быть у этого практическое применение?
могу предположить все что is_object($var) — а где пригодиться?
пока думаю только прокси объекты — которым важно что через них был передан какой-либо объект, лишь бы только объект
Что касается массива — думаю объекты описывающие интерфейсы массива все-таки пройдут
Навскидку:
$request = json_decode($requestBody);
process($request); // function process(object $request)
\stdClass — это исторически такая затычка для вопроса "что делать, если массив прикастили к object". Object же — это любой объект.
Согласен, что пример с json_decode не очень. Приведу пример получше — универсальные ORM, которые способны работать с Plain PHP Objects через Reflection, типа Doctrine 2.
Скорее его абстрактный суперкласс :)
Какое может быть у этого практическое применение?
$container->get(SomeObject::class); // object
$entityManager->find($id); // object | null
по сути это нужно там, где вы делаете проверку на is_object
и вас не интересует все остальное. Далее статический анализатор уже может убедиться в том что там на самом деле будет какой-то объект, а не строка. Это просто чуть сужает количество вариантов того что вы можете получить. Еще выгодно для чего-то что на рефлексии завязано например, где конкретный тип вам не интересен, а важно что это именно объект.
DI container?
Технически тип object заменяет в некоторых случаях сообщения типа Call to a member function <method>() on <non-object-type>)
на Argument 1 passed to <method>() must be an object, <non-object-type> given.
или выброс исключений при проверках типа if (!is_object($param)) throw new Exception('$param must be object')
. Если таких ошибок у вас не встречается, то он вам особо и не нужен, да. Но на моей практике, это один из самых (если не самый) распростаненных типов рантайм ошибок в синтаксически правильном коде. Есть надежда, что синтаксические анализаторы теперь будут лучше ошибки такого плана выявлять.
PHP-Дайджест № 121 (20 ноября – 10 декабря 2017)