StdClass. Зачем это нужно?

А в smarty удобнее писать $а.name чем $а->name. Не вижу преимуществ

Victor Golovko: а на смарти уже можно взять и запилить приложение без пыха?

stdClass создан именно для кастинга. а видеть или не видеть примущества - это дело сугубо личное.

а причем тут "без пыха", если вы говорите об "удобствах сокращения". Я вам показал пример, когда это вредно, ибо в смарти это выглядит более лучше (короче).

DevMan: А почему не возвращать объект объявленного класса вместо std? будет же автокомплит работать, DI, все дела? зачем STD?

Victor Golovko: при том, что смарти - это отдельное решение с ограниченной областью применения, а stdclass и доступ к свойствам - ядро языка.

Victor Golovko: > А почему не возвращать объект объявленного класса вместо std?
и окуда его брать? где он объявлен?

DevMan: >а stdclass и доступ к свойствам? К каким? Они же создаются динамически, и я не знаю что в них есть, будет или было.
> и окуда его брать? где он объявлен?
Объявлять и брать :)

DevMan: Хороший пример это модельки какой нибудь ORM. Объявил и взял. Доступны все публичные свойства объекта. Глядя на класс, можно понять что за свойства и методы у него. А у std? А может он пришел урезанным (битые данные)?

Victor Golovko: > Они же создаются динамически, и я не знаю что в них есть, будет или было.
в массиве они тоже создаются динамически, например, при json_decode, но это же не трагедия?

stdClass - пустой класс, у которого изначально нет ни методов (вообще), ни свойств (можно создать динамически).
если у вас уже есть класс, то зачем мы сейчас вообще трем за std?

DevMan: >то зачем мы сейчас вообще трем за std?
Зачем он тогда нужен, я же и спрашиваю. Если у него нет вообще никаких преимуществ и данные в нем легко можно модифицировать, затереть и т.д.

Каждую передачу std объекта в метод нужно валидировать на существование свойства. Например при изменение разработчиком класса можно зайти в него и посмотреть что изменилось и добавить какие то изменения в код. А как проследить изменения в stdClass? Нужно просмотреть весь проект, чтобы определить места, где он мог измениться!

> в массиве они тоже создаются динамически, например, при json_decode, но это же не трагедия?
Трагедия! Для этого и существуют классы, чтобы данные были задокументированы. json_decode чаще всего данные извне, которые валидируются в соответствии с типом ожидаемых данных

Victor Golovko: в любом классе публичные свойства можно модифицировать, почему этот должен быть исключением?

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

DevMan: > в любом классе публичные свойства можно модифицировать, почему этот должен быть исключением?
В любом классе свойства можно/нужно сделать приватными а в стд... По моему мнению ООП для того, чтобы классы были предсказуемы и на основании их описания можно было понять их зону ответсвенности, понять какой тип/данные возвращает, скрыть разрешить изменение этих данных.
Стд еще хуже чем массив себя поведет ибо объекты передаются по ссылке и затереть данные случайно очень просто (тоже самое, что и по ссылке массивы обрабатывать)

На самом деле тут спор не о том, что лучше, а что хуже. Зачем нужен std, если у него нет преимуществ над массивом

Victor Golovko: ваша ошибка в том, что вы воспринимаете stdClass как полноценный класс, коим он не является.
воспринимайте его как структуру данных, которую либо можно применять, либо нельзя, в зависимости от задачи и личных предпочтений.

PS до реализации array dereferencing stdClass дополнительно давал плюшки в синтаксисе, сейчас этого уже нет.