On 18 Feb 2004 at 11:02, Brad Fisher wrote:
> For one because PHP doesn't allow method overloading. If I have
a method
> A::foo($a), and I want to change the prototype in B to B::foo($x,
$y), then
> there is no way for me to call the original A::foo. I could use
optional
> params to emulate this, and I do as often as possible, so it typically
isn't a
> problem.
>
> Also if I know A::foo does something I need/require, and C::foo
does the
> something a little different, and I also know A::foo is compatible
with C, why
> shouldn't I be able to do this? Or are you saying I should add a
method to C
> (like C::A_foo) which then calls A::foo internally? I'd hate to have
to add
> such wrappers in all cases, though I suppose it could work as well.
Sounds very weird to me. When C overrides a method, the new one
should essentially do the same as the old one.
In order to emulate method overloading, I think overriding is the
wrong way. What about using a variable amount of arguments:
class A {
function foo($a) {
}
}
class B extends A {
function foo() {
$args = func_get_args();
switch (count($args)) {
case 1:
return A::foo($args[0]);
case 2:
// New implementation...
}
}
class C extends B {
function foo() {
$args = func_get_args();
switch (count($args)) {
case 1:
return B::foo($args[0]);
case 2:
return B::foo($args[0], $args[1]);
case 3:
// ...
}
}
> That is potentially true, but if I intentionally coded the objects to
ensure
> compaitibility, then where's the problem? As mentioned above, it
helps with
> getting around the missing method overloading. In my opinion, a
programming
> language should enable the programmer to solve problems in
ways that make
> sense for the situation. One of the great strengths of PHP is that it
allows
> a lot of flexiblity. While it's true that such flexibility can be abused,
it
> can also be put to uses the original designers never anticipated.
Nevertheless even PHP should have some fundamental rules...
Programmers should try to avoid "dirty" hacks and work arounds
whereever possible.
> Well, I guess I'd argue that Perl supports such calls (via
> $obj->SomeClass::method() syntax)... Not that I'm saying that
PHP should be
> Perl, I much prefer coding in PHP!
Well, I must confess that I do not know Perl (perhaps I'm to young).
But I said "not available in any OO language" - neither Perl nor PHP
are OO languages in my opinion (like Java, C++) so we should not
use Perl as a role model here :-)
> Anyway, the "feature" was in PHP4, and people have used such
constructs. Just
> spend a little while looking through the comments for the
Class/Object
> functions in the PHP manual and you'll see examples that others
have posted to
> do this for PHP4.
This is not even a "feature". I think it was a bug which some guys
used for dirty hacks and work arounds (Often the difference between
a bug and a feature is very small). Fortunately this bug has been
fixed in PHP5.
--
Ferdinand Beyer
<[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
