Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47249
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.219 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=Zp9M6m/2I4/m6QX+c63Wgzev8YV4tyKN41ZrAhhev9JIiN13fORQoLs9ZZMPHrzPWk
         KdJlGVq5yFWaLRihq/OtvqIt6yTCNgxUFdWfMGU49dE0Rh1UsFU5bm0f9DgffxqkN9qS
         1F2X8Mdz5C+HGMBX9vNiPZZCswhPwCAqNxxOI=
MIME-Version: 1.0
In-Reply-To: <10845a341003130710p58b206afmc6bd77f1d184b10e@mail.gmail.com>
References: <416155e11003121750o4b1f8e11j4c9124fdaa34a22d@mail.gmail.com>
	 <10845a341003130710p58b206afmc6bd77f1d184b10e@mail.gmail.com>
Date: Sat, 13 Mar 2010 19:45:50 -0500
Message-ID: <cf558dab1003131645h4ea0fc75yafd2435ea5b0ecf3@mail.gmail.com>
To: RQuadling@googlemail.com
Cc: Chris Trahey <christrahey@gmail.com>, fw-webservices <fw-webservices@lists.zend.com>, 
	internals@lists.php.net
Content-Type: multipart/alternative; boundary=001485f20c540b580f0481b816fa
Subject: Re: [fw-webservices] Re: [PHP-DEV] RFC - "class underloading" -or- 
	"ancestor overloading"
From: atblock@gmail.com (Abraham Block)

--001485f20c540b580f0481b816fa
Content-Type: text/plain; charset=ISO-8859-1

This is a good use of the decorator pattern. Let's say you don't like the
way Zend_Form_Element filters form names. You can decorate it with a Your
own class which overrides this, and whenever you add a new element to your
form, decorate it with this class.

On Sat, Mar 13, 2010 at 10:10 AM, Richard Quadling <rquadling@googlemail.com
> wrote:

> On 13 March 2010 01:50, Chris Trahey <christrahey@gmail.com> 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
>
>
>
> I had exactly the same issue with Zend_Soap_AutoDiscover. This class
> uses Zend_Soap_Wsdl to create the WSDL file for a SOAP service.
>
> The class was hard coded. The AutoDiscover class allowed you to supply
> a class name to handle complex types, but not in conjunction with xsd
> scalar types. The Zend_Soap_Wsdl class handled php -> xsd types and
> read docblocks for that.
>
> But if the docblock had an xsd type (xsd:datetime, xsd:token, etc.)
> which are used to tell the consumer what the type is, then there was
> no way to get these in.
>
> So, I created this patch
> http://framework.zend.com/code/changelog/Zend_Framework?cs=21379 (diff
>
> http://framework.zend.com/code/browse/Zend_Framework/standard/trunk/library/Zend/Soap/AutoDiscover.php?r1=20096&r2=21379
> )
> which allows me to supply an alternative class name in a similar
> fashion to being able to supply a complex type handler class name.
>
> This was the easiest route I could find and the least impacting (full
> BC exists).
>
> The amendment I made to allow a subclass to be used as an alternative
> is a one off hit, so maybe this technique could be used for Zend_Form
> (I assume this is the class you are needing to amend).
>
> Regards,
>
> Richard.
>
> --
> -----
> 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
>
>

--001485f20c540b580f0481b816fa--