Re: aggregate() und overload()

"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