"Stig S. Bakken" wrote:
> Well, aggregate and MI are for solving different
> problems, basically aggregate is for customizing
> objects at runtime, while MI is done at compile time.
You are right, these are different. I had a longer mail on
types and classes, and how type == class is not true in PHP,
but for example in C++ and how aggregate() made this obvious
for methods (it has always been for instance variables). But
yours is the much shorter and for the purpose of this
discussion relevant summary.
> Suggestion for new implementation:
>
> * Don't create temporary class entries, proxy all calls through
> PHP's object overloading.
>
> * aggregate() will create an instance of the aggregated class
> and store it in the aggregating object (member
> __aggregated_objects or something like that), and
> overload the aggregating object.
> The __aggregated_objects array is a hash of
> "method" => &$object.
> If a method name exists in the hash, issue a warning
> and keep the old version.
>
> * The overloaded function handler looks up undefined methods in
> __aggregated_objects at runtime.
>
> * Properties will not be aggregated
>
> * Constructors, destructors and other special methods
> (__*) will not be aggregated.
>
> It should be possible for deserialize() to recreate
> objects aggregated this way. Do you see any problems
> with this implementation?
Does serialize() and unserialize() handle references properly? I
am out of PHP and have been for quite some time now, and last
time I looked, it didn't. If it does, your approach should work,
and looks sane (aggregation by delegation, instead of aggregation
by composition, I think).
Allows us to delay or even avoid MI, which I am slightly in favor
of (but this is an aquired taste, due to education).
> I don't particularly mind removing __(set|get)_* and only have
> __(set|get). +0 on this one too.
setters, getters and wrappers are in fact fascinating, because
they allow you to
- create composite aggregates (instance variables and methods)
in userland, if you like to implement them yourself.
__call can be used to implement __delegate, which I asked
for a long time ago.
- enforce $this->_* to be private, if you like to enforce
private variables.
- enforce class == type for instance variables or methods, if
you choose it to be this way. No more spontaneous instance
variable creation, if your __put implementation forbids it.
In fact, setters, getters and wrappers provide a great
policy-agnostic mechanism to introduce policies of the
implementors choosing.
Kristian
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
