Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47295
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.59.243 cause and error)
To: internals@lists.php.net
Date: Mon, 15 Mar 2010 16:43:24 -0500
User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; )
References: <416155e11003121750o4b1f8e11j4c9124fdaa34a22d@mail.gmail.com> <201003151414.38346.larry@garfieldtech.com> <ffa0ace81003151308r712f2ce2paeba4242c0d0eb7c@mail.gmail.com>
In-Reply-To: <ffa0ace81003151308r712f2ce2paeba4242c0d0eb7c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-ID: <201003151643.24381.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"
From: larry@garfieldtech.com (Larry Garfield)

On Monday 15 March 2010 03:08:28 pm Nate Gordon wrote:

> > 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.

Certainly true; it's not PHP's job to work around framework flaws.  However, if 
PHP can make it easier to make frameworks that don't have common flaws, that is 
something it can and IMO should do.

Traits wouldn't fix the issue mentioned here, but might allow the framework to 
be written in a way that doesn't have, or at least ameliorates, these sorts of 
issues.

Or perhaps there's a different approach besides traits that would work better.  
I dunno. :-)

--Larry Garfield