А где все это количество неграмотного хейта? Я со времен фрактала плохого дизайна (10летней давности вообще-то) ничего и не видел, а вот противопоставления эти вылезают регулярно.
Мне мешает знания языка, для тех.документации хватает, а вот разговорный...
И еще очень не люблю бюрократию, это надо с визами, закрагками и прочей кипой документов морочиться, а я не люблю бюрократию. Я даже на отдых за границу не езжу, как представлю себе всю эту вознь с документами - уже и ехать никуда не хочется.
В качестве помогайки вполне можно и ассоциативный массив использовать. Если без динамических полей упростится и ускорится код интерпретатора - то грех их не выпилить. Можно даже без атрибута #[AllowDynamicProperties]. А кому уж очень нужны именно динамические поля - __get/__set в помощь.
Можно еще чуть обобщить, до "запрет изменений", тогда применение финала к полям впишется в ту же логику.
3. И все-таки у варианта с классами есть один существенный недостаток - придется писать много кода. По классу на каждый вариант представления + все по классу на каждую вложенную структуру. А так же решать, куда это все добро размещать и как именовать. И билдить это добро каждый раз. А чем отличается фрактал от обычного json_encode - я вообще пока не догнал.
Ну то есть мы видим два разных поведения в зависимости от того, к чему применен финал - для классов одно, для методов - другое. Вполне логично, если для полей оно будет третьим.
Не понял, в чем тут принципиальная разница.
Атрибуты до сих пор не всеми библиотеками поддерживаются.
А зачем было придумывать новое ключевое слово "readonly"? В пыхе уже есть ключевое слово "final", которое можно было бы заюзать для этих целей.
Опять же зачем было запрещать значения по умолчанию? Ну было бы это свойство де-факто константой, ну и что? Наоборот удобно, можно было бы вешать на них аннотации сериалайзера, которые на обычные константы не повесишь. И в строку с двойными ковычкаи их пихать можно, в отличии от текущих констант.
Дело в том, что вуз не дает каких-либо сакральных знаний, вся информация опубликована в свободном доступе. Если человек хочет учиться — он будет использовать все доступные ему источники информации, у кого-то это будет вуз, у кого-то курсы, у кого-то книги, у кого-то родственники. А если он учиться не хочет — то никакой вуз ему эти знания в голову не впихнет.
__toString() же не мешает никому. Этот метод вполне вписывается в концепцию языка и найдет свое применение. В других языках аналогичные вещи тоже есть.
Привет из еще более далекого будущего. С десятилетием, дайджест php!)
А где все это количество неграмотного хейта? Я со времен фрактала плохого дизайна (10летней давности вообще-то) ничего и не видел, а вот противопоставления эти вылезают регулярно.
Мне мешает знания языка, для тех.документации хватает, а вот разговорный...
И еще очень не люблю бюрократию, это надо с визами, закрагками и прочей кипой документов морочиться, а я не люблю бюрократию. Я даже на отдых за границу не езжу, как представлю себе всю эту вознь с документами - уже и ехать никуда не хочется.
Почему нечего? В чем разница между жизнью без девушки в России и жизнью без девушки за бугром?
В качестве помогайки вполне можно и ассоциативный массив использовать. Если без динамических полей упростится и ускорится код интерпретатора - то грех их не выпилить. Можно даже без атрибута #[AllowDynamicProperties]. А кому уж очень нужны именно динамические поля -
__get/__setв помощь.Можно еще чуть обобщить, до "запрет изменений", тогда применение финала к полям впишется в ту же логику.
3. И все-таки у варианта с классами есть один существенный недостаток - придется писать много кода. По классу на каждый вариант представления + все по классу на каждую вложенную структуру. А так же решать, куда это все добро размещать и как именовать. И билдить это добро каждый раз. А чем отличается фрактал от обычного json_encode - я вообще пока не догнал.
Ну то есть мы видим два разных поведения в зависимости от того, к чему применен финал - для классов одно, для методов - другое. Вполне логично, если для полей оно будет третьим.
Не понял, в чем тут принципиальная разница.
Атрибуты до сих пор не всеми библиотеками поддерживаются.
Не сложно, просто дорого.
А зачем было придумывать новое ключевое слово "readonly"? В пыхе уже есть ключевое слово "final", которое можно было бы заюзать для этих целей.
Опять же зачем было запрещать значения по умолчанию? Ну было бы это свойство де-факто константой, ну и что? Наоборот удобно, можно было бы вешать на них аннотации сериалайзера, которые на обычные константы не повесишь. И в строку с двойными ковычкаи их пихать можно, в отличии от текущих констант.
Еще дженериков добавить - и будет на скалу похоже
Во вторых не сломает, так как по умолчанию останется таким же, как и сейчас.
Полифилы и прочие пакеты нужны были для древних версий пыха, начиная с 7.3 эта функция идет в стандартной поставке.