ведь раньше так и писали
function inc(&$num) { $num++; } 
$i = 0;
inc(&$i);
var_dump($i); // int(1)

семантика отличалась. До php 5.4 вы таким образом передавали явно ссылку. Причем даже если функция собиралась по значению работать, так же можно было ссылку передать. Сейчас вы получите ошибку "call-time pass-by-reference". Предлагаю чуть поменять семантику — что бы указание на стороне вызывающего явной ссылки никак не влияло на рантайм и только на читабельность.

Да, формально семантика отличалась, но фактически вменяемые разработчики использовали именно так, как предлагается в нынешнем RFC. Когда вышел 5.4, я сильно недоумевал такому решению и, матерясь, вычищал амперсанды в вызовах по всему коду (благо, такого было немного).

Т. е. предлагают грубо говоря добавить еще один вид комментириев? Обоснование в RFC есть такое:
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 то добавление этой метки выкинет ошибку.

Я в таких случаях представляю, как кто-то, кого я учу php, спросит у меня: а что делает амперсанд перед аргументом функции? А мне придётся сказать: ничего не делает.

если функция принимает аргумент не по ссылке, то на такой код должно ругнуться.
доп. защита от описок.

Показывает, что переменная передаётся по ссылке. Явное лучше неявного и всё такое.

Я был бы за, если бы альтернативный синтаксис запретили. Хотя бы notice. Я видел, что в rfc говорится о том, что потом планируют и это предложить, вот в этом случае будет явное вместо неявного. Но сама по себе эта фича, на мой взгляд, просто внесёт путаницу.

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

Хм, вы правы. По моей логике получается, что наличие override в джаве плохо. Если ide будут подсвечивать пропущенный амперсанд, то полезная фича. Благословляю, можно принимать RFC :)
Будут, куда денутся ;)

Не могу понять зачем ввели тип object. Все равно когда нам нужно, гарантировать определенное поведение объекта мы делаем тайпхинт через интерфейс. А что по сути начит object — хоть что лишь бы не скаляр, массив, null и ресурс. Какое может быть у этого практическое применение?

могу предположить все что is_object($var) — а где пригодиться?
пока думаю только прокси объекты — которым важно что через них был передан какой-либо объект, лишь бы только объект


Что касается массива — думаю объекты описывающие интерфейсы массива все-таки пройдут

Навскидку:


$request = json_decode($requestBody);
process($request); // function process(object $request)
Получается, еще один stdClass?

\stdClass — это исторически такая затычка для вопроса "что делать, если массив прикастили к object". Object же — это любой объект.


Согласен, что пример с json_decode не очень. Приведу пример получше — универсальные ORM, которые способны работать с Plain PHP Objects через Reflection, типа Doctrine 2.

Почему то я думал, что все объекты в PHP наследуют stdClass. Как же сильно я заблуждался. В таком случае Object — это то, что действительно давно пора было добавить в язык.

Скорее его абстрактный суперкласс :)

Какое может быть у этого практическое применение?

$container->get(SomeObject::class); // object
$entityManager->find($id); // object | null

по сути это нужно там, где вы делаете проверку на is_object и вас не интересует все остальное. Далее статический анализатор уже может убедиться в том что там на самом деле будет какой-то объект, а не строка. Это просто чуть сужает количество вариантов того что вы можете получить. Еще выгодно для чего-то что на рефлексии завязано например, где конкретный тип вам не интересен, а важно что это именно объект.

Вот, кстати, на подобных примерах хочется еще раз пустить слезу по поводу отсутствия в PHP Generics. :-)

Например, что-то вроде универсального гидратора?
Любой контейнер зависимостей. Сервис локатор. Гидратор. В ОРМ найдется применение

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'). Если таких ошибок у вас не встречается, то он вам особо и не нужен, да. Но на моей практике, это один из самых (если не самый) распростаненных типов рантайм ошибок в синтаксически правильном коде. Есть надежда, что синтаксические анализаторы теперь будут лучше ошибки такого плана выявлять.

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