Фокус в том что оно не везде нужно. А там где нужно подобные вещи обзываются мапперами/валидаторами/фильтрами. Просто без полноценной поддержки кастомных типов, я бы, прямо скажем, задолбался описывать вот это все. Поэтому я пользовался для некоторых вещей кодогенерацией. Для вычисляемых полей - сброс кеша в измененных полях - неудобен Возможно стоит это централизовать для всех полей по аналогии как сделано в Zend_Db_Table_Row PHP: <?php protected $_data = array(); protected $_modified = array(); Соответственно вычисляемое поле будет само проверять есть ли измененные свойства. Да и сам вопрос такого кеширования для объекта - спорен. Чего экономим? Пару вызовов методов? Для объектов PHP: <?php return clone $val; возврат клонированной сущности тоже под вопросом... Мягко говоря идет вразрез с типичным использованием объектов. Лучше это оставить на усмотрение пользователя api Этого не понял Код (Text): _call($name, $args) set_($var) get_($var) Последние два зачем-то должны отработать для пустой переменной? А в первом вообще не вижу смысла.
типизация? а кто-то заставляет использовать везде? ни один из этих терминов не отражает суть. да и какая в сущности разница как что называть? ну не так уж много кода получается, чтобы уж на стенку лезть а вот это действительно вредная практика угу. плохой пример. тем более, что сброс кэша у меня происходит даже если после присваивания значение фактически и не поменялось. PHP: <?php protected $_data = array(); protected $_modified = array(); вот очень бы не хотелось хранить все данные в одном поле. ибо это создаёт проблемы при наследовании с добавлением новых полей. но можно ввести какое-нибудь поле $_backup=array() куда складировать прошлые значения. угу, и будет однонаправленная зависимость кода, а не двунаправленная как у меня. это гораздо менее геморройно поддерживать. кэширование, разумеется, нужно лишь там, где получение значения - это дорогостоящая операция. отнюдь. если позволить пользователю получить ссылку на внутренний объект, то он может его модифицировать в обход внешнего объекта. в ряде случаев это может привести к печальным последствиям. короче нужно смотреть по ситуации. эти методы предназначены для опциональной перегрузки в дочерних классах. _call позволяет перехватывать вызовы несуществующих методов, не нарушая апи пропертей. get_ и set_ - это фильтры по умолчанию для тех свойств, для которых не заданы методы get_* и/или set_*
если ты про оффтопик ( http://habrahabr.ru/blogs/php/95157/ ), то там нет ничего из перечисленного тобой.
tenshi блин, причёт тут оффтопик, я говорю о том что ты спросил. И еще на счет этого - у тебя полный бред, как ты можешь так говорить, если ты их используешь! Вывод, может он и не верный с твоей точки зрения, то много людей могут так и понять, что ты сам не понимаешь что и зачем ты делаешь!
вот и я не знаю при чём тут он. все видят адаптивную типизацию и как быки несутся на красную тряпку. я с помощью камня заточил топор и предлагаю им рубить дрова, а не камнем. развиваем логическое мышление, товарищи.
аа, ты об этом, да... А вот знаешь почему? Я об этом немого упомянул, но надо уточнить, когда люди смотрят твой код - они, допустим как программисты (по другому лучше тут не говорить ) не видят функционала который ты предлагаешь, то есть твой код не интуитивно понятен, что может характеризовать твою идею не с хорошей стороны. Я понял твою идею, и не смотря на то, что ты говоришь про красную тряпку, она завязывается на предложенном тобой оффтопике. Я тебе предлагаю делать это внутри __get и __set, специфично для конкретной реализации владельца свойств и отдельными объектами!