Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47294
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=QZ+XMZpOhZKkbcgO1AM6D9AfGm9XuQL9Bh0r0UlOI3tmwWRWXV2TUt142MZivN7JBT
         zqhcXW9z/jW2xEMCzpNScUIa+YC/wp5T9S9CqcOteEJQ0aLjgTWksPYokui/alxNPsD1
         B5Ym36nDQklhomQrDbf++rulhEM2D8uw9Qn+U=
MIME-Version: 1.0
In-Reply-To: <201003151414.38346.larry@garfieldtech.com>
References: <416155e11003121750o4b1f8e11j4c9124fdaa34a22d@mail.gmail.com>
	 <10845a341003130710p58b206afmc6bd77f1d184b10e@mail.gmail.com>
	 <4b9a3c081003151036h73774c2di6b34cdbf71d6a1b1@mail.gmail.com>
	 <201003151414.38346.larry@garfieldtech.com>
Date: Mon, 15 Mar 2010 15:08:28 -0500
Message-ID: <ffa0ace81003151308r712f2ce2paeba4242c0d0eb7c@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e6db2999cef9110481dc716b
Subject: Re: [PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - "class 
	underloading" -or- "ancestor overloading"
From: nlgordon@gmail.com (Nate Gordon)

--0016e6db2999cef9110481dc716b
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 15, 2010 at 2:14 PM, Larry Garfield <larry@garfieldtech.com>wrote:

> The challenge of "never use extend" is that simply wrapping classes in
> decorators only goes so far.  You can't always maintain interface
> compliance
> if you're nesting decorators, and if you're overriding only one out of a
> dozen
> or two methods then you have a lot of foo() { return $obj->foo(); } method
> implementations.  Aside from being hard to read, that also eats up cycles
> for
> the extra stack calls.  __call() can make it much less code but is also
> much
> slower.
>
> If there were a syntactic-level support for "wrap this object in this class
> and pass through any method that isn't redefined", a sort of sideways
> extends,
> that would become much simpler.  I'm not sure what that would look like,
> though.
>
> Or perhaps this is a good time to revisit the traits proposal from a few
> months back?
>

While traits do seem pretty cool, the fundamental problem appears to be that
Framework X doesn't let me do what I want.  Unfortunately that is the side
effect of using a framework, it does things for you.  I had attempted to
build a system like this in userland code to dynamically replace classes in
my framework, but scrapped it because I could only see ways in which it
would be abused.  If someone replaces a class buried in a framework, that
modifies some bit of functionality, which is depended on by a completely
unrelated area of the framework, it could potentially cause issues that
would be very hard to track down.  This sounds a lot like aspect oriented
programming in the ability to completely overwrite a function with userland
code.

I feel like the better solution is to fix the framework to allow the
flexibility to do what you want in a controlled manner, and not bend the
language to fix the framework.  I don't mean to say that PHP is problem free
or perfect, but I'm not sure this is the best method to fix the problem at
hand.

-- 
-Nathan Gordon

If the database server goes down and there is no code to hear it, does it
really go down?
<esc>:wq<CR>

--0016e6db2999cef9110481dc716b--