> To resolve the serialization issue, I don't have any big problems with > removing the finer-grained aggregation methods in favor of a single > predictable one. > > 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? > > For users, the major distinction here will be that the aggregated > objects will be, well, separate objects, so $this->foo() call foo in the > aggregated object, which again is cleaner and more predictable than when > class entries are merged. It'll be a little slower because of some > extra hash lookups during method calls, but that's the price.
Argh, after all the work I did. :) And that means I'd have to remove the funny comments. There is at least one problem with this approach that I see. Suppose you have $b->a where 'a' is an object aggregating some other object. The way OO is implemented currently in ZE, when you call $b->a->something(), the engine will complain that $b does not implement overloaded function calls. -Andrei * The great thing about standards is that there are so many to choose from. * -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
