Re: Decorators Revisited

In general, I think it would be nice to have something that does this for you, but I am not necessarily a fan of changing the meaning of instanceof.

That's a lot of boilerplate for each possible iteration. This is one reason people like traits so much, as it's easier to just do automated copy/paste than use the proper patterns.

Couldn't a dynamic trait be a better? It would work like this: trait SplDynamicProxyTrait { protected $proxyObject; // enumerate all public method with the following: public function $name($signature) {

    return $this->proxyObject::$name($signature);

} } usage would then be the following: class MyDecorator implements FooInterface { use SplDynamicProxyTrait; // compile time "code generation" public function __construct(Foo $foo) {

     $this->proxyObject = $foo;

} // override trait public function method2($a) {

    if (!$this->hasCache('method2', $a)) {
      $ret = $this->proxyObject->method2($a);
      $this->setCache('method2', $a, $ret);
    }
    return $this->getCache('method2', $a);

} }

So, example code like: class Foo {} class Bar extends SplDecorator {} $b = new Bar(new Foo); var_dump($b instanceof Foo); // true It also works with type hints: function test(Foo $f) {} test($b);

These would all still work, instanceof would actually be an instanceof though.

Now, there's a lot more to do (property cascading, interface validation, etc), but the initial proof-of-concept is there.

What do you think? Is this a route that I should continue down? Or is there something fundamental that I'm missing here? I know that Reflection, get_interfaces(), etc would need to be updated to account for this. Thoughts?

In the above scenario, we've reused traits and we haven't broken instanceof or the liskov principle (which basically your implementation does since SplDectorator bypasses all method signature checking until runtime). Thoughts? :) -ralph