Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47233
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain me.com designates 17.148.16.99 as permitted sender)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii
In-reply-to: <416155e11003121750o4b1f8e11j4c9124fdaa34a22d@mail.gmail.com>
Date: Sat, 13 Mar 2010 09:31:30 -0800
Cc: internals@lists.php.net
Message-ID: <986420AE-0C93-4EAF-AEFA-C1423FCACF44@me.com>
References: <416155e11003121750o4b1f8e11j4c9124fdaa34a22d@mail.gmail.com>
To: Chris Trahey <christrahey@gmail.com>
Subject: Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"
From: paulchandler3@me.com (Paul E Chandler III)

It seems to me that you could transparently sub-class any framework's base classes with an autoloader implementation... without needing to alter the code that consumes them. You could also "inject" the code as part of your build & test automation. Perhaps you could even make due with an AOP extension to PHP.

On Mar 12, 2010, at 5:50 PM, Chris Trahey wrote:

> Perhaps a new concept in class-based OO programming, I'm not sure.
> 
> Depending on your perspective you could call it ancestor overloading (or
> upstream overloading) or class underloading.
> 
> 
> We are increasingly developing with the aid of frameworks & libraries. In
> fact, this idea came from my current project using the Zend Framework.
> 
> These libraries, while greatly extensible, are also fairly self-extending.
> That is, they include many classes that extend many classes, which is great.
> 
> As consumers of these libraries, we can extend the classes and consume the
> API however we please, but there is one sticking point.
> 
> We cannot change classes that many other classes extend without extending or
> changing each child class and then making sure that our code uses the new
> class.
> 
> 
> For a concrete example, I was working with the Zend_Form_Element subclasses,
> and I realized that I wanted to change some of the default behavior (in
> Zend_Form_Element).
> 
> - at this point I will assume the reader understands why I wouldn't want to
> just start changing the Zend library files -
> 
> There are many subclasses of Zend_Form_Element. If you want to change the
> default behavior for all of them, you have 3 choices currently:
> 
> 1. Directly edit the Zend_Form_Element file in the library, -bad for updates
> & other projects that use the library
> 
> 2. subclass Zend_Form_Element and change declaration of the descendants to
> extend new class - same problems
> 
> 3. extend each child class and implement those subclasses in your app code
> -very tedious and TONS of repeated code, breaks consistency of API for
> developers.
> 
> 
> There could be a better way, if we could insert a class into the family
> tree.
> 
> And that's the heart of this idea, so I'll repeat it:
> 
> * insert a class into the family tree *
> 
> 
> Image we do it using an alternative keyword to "extends", such as
> "overloads".
> 
> 
> Example:
> 
> 
> class Library_Class { }
> 
> class Library_Subclass extends Library_Class {}
> 
> and then:
> 
> class My_LibClass_Overload overloads Library_Class{}
> 
> 
> Now new instances of Library_Subclass actually extend My_LibClass_Overload,
> which "extends" Library_Class. The developer would then code
> My_LibClass_Overload as if it were declared like this:
> 
> class Library_Class {}
> 
> class My_LibClass_Overload extends Library_Class {}
> 
> class Library_Subclass extends My_LibClass_Overload {}
> 
> 
> But indeed the declaration of Library_Subclass would *not* have to change.
> 
> 
> This way developers could "extend" default functionality and have *existing*
> library classes pick up the new functionality without redeclaring anything
> in the library.
> 
> Downstream classes would still override any methods that they redeclare. If
> you wanted to have end-point classes in the library have different behavior,
> you would overload them instead, such as
> 
> class My_LibSubclass_Overload overloads Lib_Subclass {}
> 
> 
> The benefit is that the application code can still consume "standard"
> classes, such as Library_Subclass and not need to know or care about the
> extended functionality.
> 
> 
> Going back to my concrete example, my code could then still use
> Zend_Form_Element_Text, but benefit from the modifications I added, without
> me having to touch the library code.
> 
> 
> I hope I've explained clearly what this could look like. I'm a younger
> developer, so forgive me if I'm rough on the terminology -perhaps
> overload/underload is not the best word for this functionality. Also, I'm
> not sure if there are other class-based OO languages that allow this kind of
> behavior... Prototypal languages perhaps, as is the case with javascript and
> the Obj.prototype which (combined with anonymous functions) allows you to
> extend the "base" functionality of other objects that "extend" it.
> 
> 
> Thank you for your comments and thoughts!
> 
> 
> Chris Trahey
> 
> Web Applications Developer
> 
> Database Administrator
> 
> CSISD [Technology]
> 
> 
> footnote: I sent this message from a different address and it did not show
> up. I tested sending to internals-help@lists.php.net and did not get a
> response -so I assume there is an outgoing issue on my other server's side.
> Forgive me if this message shows up again.