Re: Re: [fw-webservices] Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"

From: Date: Tue, 16 Mar 2010 00:24:45 +0000
Subject: Re: Re: [fw-webservices] Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-47297@lists.php.net to get a copy of this message
On 15 March 2010 21:43, Larry Garfield <larry@garfieldtech.com> wrote:
> 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

The ability to "registerASubClassForThisClass" idea (don't know the
proper name for this), has certainly worked for me.


-- 
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling


Thread (12 messages)

« previous php.internals (#47297) next »