Without cluttering the RFC list up further (I fear I've done too much
of that with the last two bombed suggestions), I'd just like to come
out and ask if the addition of an override keyword on classes had ever
been considered? I'd see it as more than a self documenting thing for
BC reasons than anything else since, for BC we have to allow functions
to override even if they don't have the keyword. But if a method is
declared as an override, and none of the parent classes or imported
traits have that method, then stating override would be a fatal error.
Or, given...
class A {
public function foo() {}
}
class B extends A {
public function foo ( $val ) {}
}
This is ok to avoid a backwards compat break, though if a move to
require the override keyword was desired an E_STRICT might be raised.
class C extends A {
public override function foo ( $val ) {}
}
The only real advantage I will admit is self documentation by the
code. We know C's foo is overriding something without opening A's
class file.
class D extends A {
public override function bar ( $val ) {}
}
And this would raise E_FATAL. No existing code would be affected, and
a programmer using this keyword would, I assume, want to be alerted
that the override they are expecting doesn't exist. After all, if
their override calls the parent method, they'd get an error anyway.
I can write an RFC for this, but the last two I wrote got shouted down
in such swift succession I think it would be better to get this vetted
before writing the RFC.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
