Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62157
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ralphschindler.com from 209.85.216.42 cause and error)
Message-ID: <502AA750.1060406@ralphschindler.com>
Date: Tue, 14 Aug 2012 14:30:24 -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>
In-Reply-To: <CAAyV7nFMONBrp-zBW1gvjsrTZMVvn-TNZtNUwa5g=aEttfpsWQ@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)


> Well, I like it at first glance. There are two main problems that I see
> with it:
>
> 1. It still requires a separate decorator class for every combination of
> interfaces you want to decorate. So, for example if you wanted to
> decorate a Foo interface, but sometimes it's used with Iterator as well.
> Then you'd need two classes. If there was a third interface, you'd need
> four separate classes. Same problem with class bloat minus a lot of the
> boilerplate.

You'd need a class anyway for your custom logic to live, that custom 
logic is the reason you want a Proxy in the first place.  In your 
example, you want to proxy and object, but for one of the method, 
presumable an expensive method, you want to be able to cache the output 
before needing to go to the actual object.

If Iterator was required for the Foo contract/interface, that would have 
bee in the Foo interface definition as well.

Even in your example, you still have this:

   class Bar extends SplDecorator {}

But what you are really intending is:

   class Bar extends MagicToMakeThisActLikeAnyType {}

Ultimately, the instance you are decorating and decorator itself need to 
be "type equivalent".  Meaning the generally accepted understanding of 
is_a() and instanceof constructs need to also apply to the decorator 
object just as it would any other object.

> 2. It's still not possible to decorate a typed class. So I can't
> decorate PDO without first extending PDO with a user-supplied interface.

I don't follow.  What do you mean by a "typed class"?

> And I don't understand how this breaks LSP... We're not extending the
> decorated class. In fact, we can add construct time checking to ensure
> the original interfaces are all enforced (and even go a step further and

That is where we are going to differ.

Simply because your object responds to all the same methods of, for 
example, the FooInterface, does not make it a FooInterface subtype.  It 
just means that in the "duck typing" sense of the phrase, it can act 
like a FooInterface for people that are not necessarily concerned that 
it's actually not is_a() FooInterface.

In other words, yes, it will pass all sorts of method_exists() checks, 
but it'd never be able to pass an instanceof, is_a, or is_subclass_of() 
check on FooInterface.

> ensure that all method signatures are the same that are overridden). LSP
> is not a compile time concern, it's a purely runtime concern (in PHP at

When I say "compile time" I mean PHP's compile time, in so far as PHP is 
a compile and execute style interpreted language.

The following script demonstrates the enforcement of subtype expectations:

<?php
interface Foo { public function bar(); }
class Bar implements Foo { public function bar(array $a) {} }
?>

That will produce: PHP Fatal error:  Declaration of Bar::bar() must be 
compatible with that of Foo::bar() in ...

That is an LSP check, and it is done at PHP's compile time.  The rule 
"Preconditions cannot be strengthened in a subtype" is violated since 
you attempted to add an argument to the bar() method of the Foo contract.

> least). The fact that interface contracts are enforced at compile time
> is nice, but it's not a strict necessity to enforcing LSP.

Why not do it at compile time? When php is building up its class entry 
table, it should be in its best interest to not have incomplete or 
invalid types in there, right?


But, I do support getting more duck typing facilities in PHP, and 
reusing traits in places where we need more compiler assisted copy/paste 
when boilerplate is cumbersome.

-ralph