Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47381
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=references:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:x-mailer:mime-version:subject:date:cc;
        b=moNihoKyevz3ybvgnqIy2bQCQDPDYwjAGXPp1wLVpJzxFQ4wDi6bJ0vEh6kNALav8j
         vAqgDAYb8lhTDy1EOPFglwQVbQju1bRIiR2FU3jBXe9xizysqDzkg2N0pmBJNA+9vXwe
         P6zaT1inYlux09xx2cuVbBGcOygM4lJPx51mU=
References: <fc.00870cc10592ff3800870cc10592ff38.593056e@csisd.org>
Message-ID: <22AE7C0E-731A-473E-A14D-451B911F5495@gmail.com>
To: Chris Trahey <ctrahey@csisd.org>
In-Reply-To: <fc.00870cc10592ff3800870cc10592ff38.593056e@csisd.org>
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 7D11)
Date: Wed, 17 Mar 2010 15:55:26 -0500
Cc: "internals@lists.php.net" <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"
From: christrahey@gmail.com (Chris Trahey)

Sorry for duplicate message- mail server fail.

Chris Trahey
Web Applications Developer
Database Administrator
College Station I.S.D.

On Mar 12, 2010, at 5:37 PM, "Chris Trahey" <ctrahey@csisd.org> 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]
>
>