Hi,
The feature specified by Chris remind me the "metaclass" extension system of
Groovy language (I am not a Groovy Expert, but properties seems similar).
+1 for this kind of feature at a language level, IMHO it will really help
for Aspect Oriented Programming, Legacy Code Refactoring, Unit Testi
Hi:
On 13 Mar 2010, at 00:37, 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.
Haven't read the term in this thread yet, so I felt obli
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" wrote:
Perhaps a new concept in class-based OO programming, I'm not sure.
Depending on your perspective you could ca
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 pr
On 15 March 2010 21:43, Larry Garfield 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
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,
On Mon, Mar 15, 2010 at 2:14 PM, Larry Garfield wrote:
> The challenge of "never use extend" is that simply wrapping classes in
> decorators only goes so far. You can't always maintain interface
> compliance
> if you're nesting decorators, and if you're overriding only one out of a
> dozen
> or t
The challenge of "never use extend" is that simply wrapping classes in
decorators only goes so far. You can't always maintain interface compliance
if you're nesting decorators, and if you're overriding only one out of a dozen
or two methods then you have a lot of foo() { return $obj->foo(); } m
I also ran into this problem with Zend_Db_Select. I wanted to add a new
constant to improve my usage of Zend_Db_Table#select(), but that method
would always returns an instance of Zend_Db_Table_Select which extended
Zend_Db_Select. There was no easy way for me to add my class constant
without resor
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, Richar
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 exte
On 13 March 2010 01:50, 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 framewor
On Mar 12, 2010, at 9:28 PM, Chris Trahey wrote:
> The old class is still there, think of it as if the inserted (overloading)
> class extends the base (overloaded) class and any classes the were extending
> the base now extend the inserted class. So as far as the runtime, it's
> run-of-the-meill in
The old class is still there, think of it as if the inserted (overloading)
class extends the base (overloaded) class and any classes the were extending
the base now extend the inserted class. So as far as the runtime, it's
run-of-the-meill inheritance. Methods that are not re-implimented in the
ins
Hi,
On Sat, Mar 13, 2010 at 2:50 AM, 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 a
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
16 matches
Mail list logo
