|
|
Posted by Richard Levasseur on 06/26/06 08:03
Tim Van Wassenhove wrote:
> On 2006-06-25, David Haynes <david.haynes2@sympatico.ca> wrote:
> > PHP5 has weak polymorphism but not true polymorphism in the sense that
> > it is used in OOP.
>
> So how would you define polymorphism? And what exactly are the
> differences between 'weak' and 'true' polymorphism?
>
> If i look at http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29
>
> "The concept of polymorphism applies to data types in addition to
> functions. A function that can evaluate to and be applied to values of
> different types is known as a polymorphic function. A data type that
> contains elements of different types is known as a polymorphic data
> type."
>
> > function __construct($one, $two="two", $three="three") {
> >
> > I cannot instantiate this object as new Foo($one, $three) since there is
> > no typing on the arguments and, therefore, no signature for a 'one,
> > three' contructor. .
>
> Imho that's the same as saying: I'm standing with my back against a wall,
> and now i'm wondering why i can't step backwards anymore...
>
> Define your constructor as __constructor($args) and handle with
> func_num_args and func_get_args(s) any number of parameters...
>
> (I do agree that the language/compiler can, probably should, make this
> easier... But that's a different discussion.)
>
> --
> Met vriendelijke groeten,
> Tim Van Wassenhove <http://timvw.madoka.be>
There are two annoying problems with this, which is why its such a nice
feature to have:
1) It is a pain in the but to have to order out and determine the types
of the passed variables. Whenever I make classes i always end up
having to spend 100+ lines trying to figure out the types of variables
passed to sort out what goes where. Why? One object returns an
indexed array, another an associative array, other return other objects
of various types. The reason for being able to call the function with
any of these types is so that I don't have to pre-process the data and
can operate more efficently on the passed value. What ends up
happening is converting everything to an array, or string, or object,
or what not. A lot of extra work on my part and the program's part
that would otherwise be handled by a compiler.
They have type hints in PHP5, but they are more like type requirements,
as it causes a fatal error and is largely useless unless you
pre-process things to match that definition. I'd much rather be able
to create multiple methods with different signatures that could be
called if the parameters match, but thats not really feasible in a
typeless language.
2) It makes overriding methods harder in derived classes. Why?
Because the overridden method is completely hidden and you must convert
parameters to what it expects to be able to use its functionality.
This happened to me while extending HTML_Table from pear. Its addRow
method accepts 2 types of arrays, and invokes different completely code
paths depending on the array type, which is determined by a private
method thats not (well, shouldn't be) accesible from the derived class.
Ideally, all i would have to do is override addRow, modify the incoming
data to match what the original addRow expects, then pass it up.
Extension with minimum effort. However, because the addRow method uses
several private methods and a bunch of code and logic to determine what
to do, I either have to:
- Duplicate all that logic and code (including the private methods,
default values, etc), then pass it up to addRow to have it done again,
which is a lot of redunant work, or
- Pass it up to addRow then modify the object accordingly, which
performs several of the same operations addRow did originally (as well
as introducing a caveat of overwriting instead of updating certain
attributes, which limits the functionality in a few cases).
If i could just override the method to accept the single object i
wanted to pass it, while the original method existed and could be
called directly, all of that could have been avoided.
Then there is the lack of multiple inheritence in PHP. Considering the
wide breadth of small operations a single object should be able to do,
its completely insane to have to rewrite the exact same interface code
again and again for the smallest of operations (a problem that rears
its head in java gui programing, when you have to implement an
interface then manually delegate all methods to an instance of a class
that has a handle back to the container, more needless complication
that could have been handled by MI). I'm getting off topic though.
Please, continue the flame war.
Navigation:
[Reply to this message]
|