Меню
Что нового?

Расширение класса внешними методами и переменными

также банально значительно усложнятся конструкторы, связанные с навороченной валидацией передаваемых на конструктор параметров.
ну а то что этот треш примут я уверен на 99%.
 
2 раза $this->a не присвоить в конструкторе. Бывает нужно редко но метко, если используются валидаторы взаимосвязанных параметров (к примеру если параметр такой-то удовлетворяет таким условиям, то обнулить параметр 2 и т.п.)
придется все костылить через промежуточные переменные, как следствие код будет менее читаемый, да и убирается автокомплит у части кода (присваиваем ключи массива, а не проперти класса)

Т.е. readonly after constructor значительно более полезная фича чем текущий треш из rfc
 
Могу предположить, что проблема тут в том, что в PHP конструктор - это не нечто особенное, а просто метод, который вызывается автоматически после создания IS_OBJECT zval-а.

Хотя могли бы и флаг типа is_construction_complete добавить, ну.
 
А как это будет работать с clone?
PHP: 
public function withFoo(...): self
{
    $bar = clone $this;
    $bar->foo = ...;

    return $bar;
}
 
Вурдалак написал(а):
А как это будет работать с clone?
Нажмите для раскрытия...
А скорее всего нормально не будет (только предположение, код патча не смотрел), т.к. будет логическая ошибка по определению:
или после клона все статусы writeonce параметров переносятся как есть (скорее всего), тогда повторно уже не присвоить, если было присвоение ранее,
или же для все writeonce параметры разлачиваются, тогда какой смысл от таких параметров (надо или повторно переприсвоить все writeonce или оставить их незаблокированными)???

Всетаки такое writeonce реально стремная вещь, даже с точки зрения IDE достоверно определить где может а где нет использоваться присваивание довольно проблематично будет
 
Последнее редактирование:
Да, похоже на то. Для language change нужно конституционное большинство, а там щас ровно 50/50.
 
Ну вообще я бы не сказал, что этот RFC трешовый. Я примерно одинаково рад final-like behavior (Java-like) и «true»-readonly (изменение только внутри области видимости). По сути, примерено одно и то же в большинстве случаев. Насколько я понял из комментариев к RFC, люди хотят больше просто readonly (не «final-like», а реальное).
 
Ну разве что вопрос семантики раздражает. Называть write-once (final-like) «readonly» — это как-то очень странно. В принципе, правильно сделали, что в текущем виде отклонили. Если бы было просто final, то было бы OK.
 
Сама по себе идея public readonly пропертей не нова и, я не побоюсь этого слова, актуальна.
Но вот такие извращения реализации - это, простите, трэш.
 
Вурдалак написал(а):
Ну разве что вопрос семантики раздражает. Называть write-once (final-like) «readonly» — это как-то очень странно. В принципе, правильно сделали, что в текущем виде отклонили. Если бы было просто final, то было бы OK.
Нажмите для раскрытия...
Вот да. Либо final как в Java, либо readonly как в C#. Я, конечно, понимаю, что полноценно то или другое сделать сложнее, чем простой булевый флаг :)

Но даже так было бы лучше, чем ничего. Если это назвать final, то даже сойдет.
 
обсуждение выбора ключевого слова - чистый bikeshedding
приколы с clone и final after constructor - это edge cases любителей нарушать SOLID задачами типа множественного наследования контроллеров, или уровень базовых классов фремвоков - а там вообще пофиг какой синтаксис
за 10 лет я писал слово clone и переопределял значение поля в конструкторе, наверное, менее 5 раз

проблемы будут у Jetbrains и Дерика, очевидно, а остальным почти пофиг как именно это реализуют, но сам факт здравого обсуждения очень радует
 
fixxxer написал(а):
Тут проблема, что об этом вообще особо не думали.
В Java все выглядит целостной и продуманной конструкцией, для уровня фреймворков - вот, пожалуйста, Reflection.
Нажмите для раскрытия...

Да не так уж все расчудесно в Java с final. Если открыть его для рефлекшена, то оно закроет путь к оптимизации производительности. Если не открывать, то получаем не всегда работающие фреймворки. final на проперти как в Java вполне себе тема. Но writeonce - очередной путь к плохому коду. Поди найди потом где оно once. В плюсах давно уже такой принцип есть - RAII. Смысл там если перефразировать - неконсистентные объекты не должны существовать. А writeonce как раз подразумевает создание некондиции. Опять же на бытовой язык перевести это вроде как осетрина второй свежести. В природе существовать может, но вряд-ли удовлетворит более менее здоровый вкус.
 
RAII это все же больше про освобождение ресурсов, типа smart pointers; в языках с GC это куда меньшая проблема. Хотя аналогия, да, есть.

С writeonce в принципе можно жить, если принять за правило использовать его как final и всегда инициализировать в конструкторе (это легко отслеживается статически). Тут, конечно, на статический анализатор перенесется работа самого PHP, но это ж PHP, тут к такому все привыкли.
 
Всякие property autowiring и прочие setter injections - это все отличные способы отстреливания себе разных частей тела.
Кто предпочитает, чтобы число конечностей оставалось константой, давно избегают любых способов, кроме классического через конструктор.
 
К слову, z-engine позволяет убирать final из классов. Там еще структуры в памяти без очистки между запросами можно объявлять.
 
Последнее редактирование:
Войдите или зарегистрируйтесь для ответа.
Сверху