Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62162
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ralphschindler.com from 209.85.214.170 cause and error)
Message-ID: <502ADCD4.6020307@ralphschindler.com>
Date: Tue, 14 Aug 2012 18:18:44 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>
CC: internals@lists.php.net
References: <CAAyV7nEZdNbWht+8Fy4ZpS=AjkzYq4Yk7XhJWV3sSV_NpgVS2g@mail.gmail.com> <502A81AD.1070303@ralphschindler.com> <CAAyV7nFMONBrp-zBW1gvjsrTZMVvn-TNZtNUwa5g=aEttfpsWQ@mail.gmail.com> <502AA750.1060406@ralphschindler.com> <CAAyV7nEtFTv3dQLWo+GJwY3nQU0izH5qm+DJdCao00sKhfmjmw@mail.gmail.com>
In-Reply-To: <CAAyV7nEtFTv3dQLWo+GJwY3nQU0izH5qm+DJdCao00sKhfmjmw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Decorators Revisited
From: ralph@ralphschindler.com (Ralph Schindler)

Hey Anthony,

There's a lot here, so I'm only going to address a few things.

> It sounds to me like you haven't tried to use decorators for any complex
> logic. Making it type equivalent leads to very vebose code. And a PITA

I actually have used both Decorators and Proxies (it's cousin) a number 
of times and some in complex situations (these are all ZF2) 
http://git.io/HdRe6g (Zend\Di), http://git.io/6EGv4Q 
(Zend\ServiceManager), and http://git.io/DhXDFA (Zend\Db Sql 
Abstraction), all that aside ...

> to write. This is one of the reasons that traits are so heralded.
> Because problems that are easy to solve with decorators (in general) are
> difficult to solve with PHP, so people wind up writing copy/paste

If what you're trying to do is decorate an instance of a particular 
concrete type, the basic structure/foundation for creating a Decorator 
(as defined by wikipedia), can be achieved in PHP with about 3 lines of 
code:

class FooDecorator extends Foo {
     protected $subject;
     public function __construct(Foo $foo) {
         $this->subject = $foo;
         foreach (get_object_vars($foo) as $n => $v) {
             $this->{$n} =& $foo->{$n};
         }
     }
}

At this point, any instance of new Foo is statefully and type equivalent 
to new FooDecorator($foo).  Now, you're free to add in your custom 
decoration logic, overridden methods, additional methods, new 
interfaces, etc.  An instance of FooDecorator can be used an any place 
an instance of Foo would have been used.  i.e., it's bound to the Foo 
context.

> Let's get one thing clear here. It's not a LSP check. In that exact
> example it is. But in general, it also prevents the LSP valid:
>
> interface foo { public function bar(array $a); }
> class Bar implements Foo { public function bar($a); }
>
> That's 100% in compliance with LSP. Yet it's disallowed. The reason is
> that interfaces are not primarily a LSP enforcer. They are primarily a
> contract enforcer. LSP is a usual side-effect, but it's not a guarantee.

I'll give you this one.

That is an example of contravariance of method arguments, which I'd 
argue should probably be allowed (if it's not that expensive to do so). 
  PHP does not specifically say it or define type sets, but one would 
assume that "no type required" should mean "all types" which technically 
might include "array".

> And I don't need to resort to duck typing for it to work. All I need is
> the ability to decorate at will. I'm not talking about nuking the
> meaning of the interfaces (as they'd be proxied to). But more just

We're going to have to disagree on the "meaning of interfaces". 
Interfaces are a foundational element of a class based type hierarchy. 
If you want Interfaces without them being in an instance type hierarchy, 
I'm not sure what you call that; but it's not an Interface. The 
decisions made in the PHP group around the class type system more 
closely resemble those made by Java and C#.

Concerning your code snippets above.

It sounds like you want to dynamically build classes and methods, on the 
fly, or you want a magical subclass that is free from the current rules 
of is_a, instanceof, etc.

Put another way, some developer somewhere built a system and has a 
method signature like

class Controller {
    public function dispatch(Dispatchable $dispatchable) { ... }
}

and they have provided the Dispatchable interface.  But you want to take 
any old object that does not implement Dispatchable and be able to 
modify it on the fly to bypass his type check in his type check in the 
method signature of his dispatch().

> to solve this problem. I'm talking about runtime composability of
> functionality. Not compile time. I want to be able to construct my
> objects from other interactions (like database settings), not just be
> limited to having to copy/paste for everything.

That's just crazy talk right there! ;)

composing functionality != composing types

In PHP (currently, as anything could change), is_a, instanceof and 
method type signatures are used by people who believe in a class based 
type inheritance system and the system of checks built around that.

Your proposal attempts to change that such that special types can be 
exempt from the type checking rules for the purpose of a particular 
pattern (Decorator).  I've personally never had a problems with 
decorating, so it is hard for me to envision the system you are building 
where Decorators are a problem.

-ralph