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" <ctra...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
