Комментарии 42
Станет не хуже, а чуть лучше? Ну ок.
Волновать? Ну уж нет, слишком мелко.
Указание свойств в конструкторе мне тоже не по душе (потому что для меня это выглядит не очевидным что это объявлены свойства объекта).
Скажу в защиту readonly, на сколько я понимаю, ключевое слово постулирует о том что php будет проверять что свойство было заполнено единожды и более изменяться не будет. В то время как в вашем варианте "неродивый" разработчик мог добавить в ваши объекты публичный сеттерт то с readonly это ему не поможет.
Весь вот этот вот церемониальный мусор в конструкторе, который был у нас до PHP 8 - это крайне раздражающий фактор лично для меня, потому что надо было в трёх местах писать абсолютно идиотский и никому не нужный инициализационный код.
Эти секунды, которые нужно тратить на пояски с инициализационным бубном, складываются в весьма неплохой кусок времени к концу дня.
Получается, что не язык обслуживает наши интересы, а мы обслуживаем язык.
Программист - это не человек, который знает языки программирования, а человек, который решает бизнес-задачи. Устранение бестолковых церемоний, мешающих этому, можно только приветствовать.
Подумайте, почему мы используем фреймворки? Для того, чтобы не писать заново повторяющийся код, который всегда будет одним и тем же.
и указания свойств в конструкторе
Ну хз, на таком например можно полэкрана скрола сэкономить (плюс еще полэкрана+ на объявление) :)
И главное не затупить при копипасте в двух местах, когда еще один сервис надо будет заинжектить. Про God классы лекции не нужны - этот класс делает именно то, для чего был создан. Он не виноват что ему много чего нужно )
Обилие сервисов какбэ намекает на альтернативную красоту архитектуры.
При передаче трех и более аргументов лучше упаковывать их в какой-нибудь отдельный объект.
А в чем смысл, если напрямую этот класс все равно не создается и вручную не надо ничего передавать ?
Пускай DI разбирается с этим.
Я бы посмотрел на тесты этого класса
Ждал этого коммента )
На самом деле тесты этого класса бессмысленны, потому что основная его работа - взаимодействие с различными, порой неизвестными (задаются пользователями) внешними API и он первый претендент на мок.
Да и вообще во всем проекте (плагин для nextcloud) половину классов надо замокать для тестов, а значит тесты не особо имеют смысл.
Максимум что можно протестировать - это то что сервисы самого nextcloud отрабатывают правильно (читай проверять 2+2=4).
В общем мне проще по старинке - протыкал кнопки и убедился что все работает )
В PHP, по историческим причинам, не всегда синтаксически просто использовать функции как значения. Например, присваивать их переменным:
php > $foo = strlen;
PHP Warning: Use of undefined constant strlen - assumed 'strlen' (this will throw an Error in a future version of PHP) in php shell code on line 1
php > echo $foo;
strlenВ PHP 8.1 для такого ввели специальный синтаксис.
Да это известная штука, однако я им пользовался всегда как
$func = 'strlen';
echo $func('ololo');
// 5Поэтому для меня стало удивлением что это еще оборачивают вто что-то дополнительно.
А по поводу введение, думаю да, теперь проще станет такое делать.
Автодополнение в IDE, рефакторинги и т.п. чувствуют себя не слишком уверенно со строками.
Интересно как иде будет чувствовать себя с
[$obj, 'doIt']Почему бы не ввести сразу какой то синтаксический сахар для имени метода объекта (а за одно и свойства) типа:
echo $obj->>doIt;
// doItА со свободными функциями как делать?
Можно придумать, главное что у нас появится способ указать для иде что мы сейчас хотим написать и на после последней > она будет подсказывать методы.
А если бы внутри вводилась бы какая то псевдо типизация то как бы хорошо это отразилось на активрекорд, когда мы сейчас пишем свойство так:
$moo->where('foo', 1)Можно было писать:
$moo->where(Moo::class->>foo, 1)А внутри была бы проверка псевдотипа:
public function where(Moo::property, $value)
Под этот RFC https://wiki.php.net/rfc/partial_function_application первый шаг был.
Весь этот "синтаксический сахаръ" - это конечно хорошо, но когда уже php превратится в альтернативу таких мощных языков как C/C++ для тех кто ничего кроме PHP не знает, для того чтобы на PHP можно было бы писать всё, как "вечно живущие" серверы для игр, так и полноценные десктопные приложения и программы?! (сарказм)
Может, ответить на ваш вопрос поможет расшифровка аббревиатуры PHP? Или все-таки стоит надеяться, что песок будем возить на спортивных автомобилях, а гоняться на самосвалах?
Никто не мешает вам демонизировать php
Боюсь, вы этот момент чуть проспали. Давно можно.
Всё правильно. Язык должен эволюционировать, чтобы угождать всем и конкурировать. Молоцы!
Если угождать всем и каждому - получится свалка из конструкций и концепций. В итоге php придет к тому с чего начинал - str_rot13 и вот это вот все.
Может, конечно, три года в go так влияют, но релизы чуть ли не полностью состоящие из syntax sugar воспринимаются как то искусственно что ли. Как будто: "мы не знали что делать с языком (но делать что то надо) поэтому вот вам гора сахара - будете экономить минуту в день при написании кода". И как то люди забывают, что код надо не только писать, но и читать, и увеличение когнитивной нагрузки при чтении это не то чтобы плюс.
Мне кажется в место readonly правильнее было бы дать возможность указать типы констант.
class Foo
{
const string bar = 'baz';
}
PHP 8.1: до и после