Знаете, я и в PHP и в любом другом языке могу такую муть навернуть, что она любой сервер подвесит намертво на сайтах с одной страничкой :) Вот вам и не бывает быстродействие в PHP узким местом…
Просто иметь доступ к приватному полю класса еще не означает наследование. Но на мой взгляд, вы совершенно правы в том, что доступ к приватным полям представляет некоторую опасность. Вообще-то я его реализовал больше для полноты картины, нежели для чего-то существенного. Без него вполне можно обойтись. Вполне достаточно того, что примесь имеет свое состояние и может вызывать, скажем, публичные методы класса, к которому подмешана. Впрочем, необходимость специального оформления агрегатора для поддержки примесей позволяет проектировать его с учетом возможностей, которые вы хотите примесям предоставить. Так что, даже доступ к приватному полю, если вы его планируете и желаете, может не быть большой проблемой.
Кстати, в моей реализации с доступом к приватным полям будут некоторые проблемы :) PHP Reflection не позволяет обратиться к приватному полю класса, определенному в предке через имя класса-потомка. Нужно обращаться через имя класса, в котором приватное поле определено непосредственно. А с этим есть некоторые проблемы производительности (требуется перебирать всю иерархию). С доступом к protected членам проблем нет.
А Страуструпп и авторы языков Common Lisp, EuLisp, Curl, Dylan, Eiffel, Logtalk, Object REXX, Scala, OCaml, Perl, Perl 6, Python, и Tcl, видимо, протупили, допустив множественное наследование в том или ином виде в этих языках? :)
Я бы не был столь категоричным. Конечно, множественное наследование имеет свои недостатки. Однако и некоторые достоинства ему тоже присущи. Недостатки же его столь существенны, что начинающим программистам, видимо, лучше вообще его в руки не давать.
Это потребует загрузки класса примеси для регистрации. А я уже говорил, что мне хотелось бы этого избежать. Кроме того, не совсем понятно, как тогда кешировать вызовы методов агрегатора. Я так понимаю, вы предлагаете от реестра отказаться?
Я просто не понял, чем вы поинтересовались :)
Декоратор и примесь — это немного разные вещи, если я правильно понимаю. Декоратор добавляет поведение в объект, а примесь — в класс. Декоратор позволяет заворачивать один объект в другой, наращивая функционал. Если рассматривать такое расширение, как вертикальное, то примесь расширяет класс горизонтально, добавляя новое поведение прямо в него, полностью сохраняя существующий интерфейс.
Магические методы действительно немного усложняют все дело в первую очередь потому, что проверки времени компиляции нет и Intellisense тоже обламывается :) Но в целом… Чего еще хотеть от динамических языков? Ведь в этом их гибкость. Если магические методы усложняют, то что можно сказать о Ruby как о языке, в котором, с точки зрения PHP, все магическое?
А какой именно вариант его использования вы предлагаете? Просто… я люблю простые вещи :) Все должно быть как можно более просто, но не проще :) Если реализовывать декоратор так, это ckmyj усложнит схему, на мой взгляд.
Если она существует много лет, означает ли это, что никак не стоит выражать свой протест в связи с этим и продолжать предоставлять государству конфиденциальные данные, которые оно не умеет хранить? Вы, может, никому и не нужны сейчас :) Но как только станете зарабатывать побольше и упомянете об источниках дохода в переписи, а также о том, что вы часто ездите за границу… :)
Завтра информация о вас появится на ближайшем рынке в виде базы данных с удобным поиском. Это одна из основных причин, по которым я отказываюсь участвовать в этой переписи. Если государство не умеет охранять информацию, которую ему передают (она ведь считается конфиденциальной), я пас.
Кстати, в моей реализации с доступом к приватным полям будут некоторые проблемы :) PHP Reflection не позволяет обратиться к приватному полю класса, определенному в предке через имя класса-потомка. Нужно обращаться через имя класса, в котором приватное поле определено непосредственно. А с этим есть некоторые проблемы производительности (требуется перебирать всю иерархию). С доступом к protected членам проблем нет.
Я бы не был столь категоричным. Конечно, множественное наследование имеет свои недостатки. Однако и некоторые достоинства ему тоже присущи. Недостатки же его столь существенны, что начинающим программистам, видимо, лучше вообще его в руки не давать.
wiki.php.net/rfc/horizontalreuse
Декоратор и примесь — это немного разные вещи, если я правильно понимаю. Декоратор добавляет поведение в объект, а примесь — в класс. Декоратор позволяет заворачивать один объект в другой, наращивая функционал. Если рассматривать такое расширение, как вертикальное, то примесь расширяет класс горизонтально, добавляя новое поведение прямо в него, полностью сохраняя существующий интерфейс.
Магические методы действительно немного усложняют все дело в первую очередь потому, что проверки времени компиляции нет и Intellisense тоже обламывается :) Но в целом… Чего еще хотеть от динамических языков? Ведь в этом их гибкость. Если магические методы усложняют, то что можно сказать о Ruby как о языке, в котором, с точки зрения PHP, все магическое?
текст цитаты
[/blockquote]
Только скобки угловые поставьте.