Hello Derick,
why the hell is everybody who is affected by some oo issue always using
this lame excuse argument over and over again. Guys do you have no real
issue? Infact why are you using oo at all if you are not willing to
follow the paradigm? Do need to find a SEGV or other problem always
before we can stick to some guidlines thought out by people who probably
knew what they were doing while developing the oo paradigm?
Coming back to the issue. You are trying to make a thing callable that
is infact never callable. Remember without late static binding a static
function will be bound to the class and a derived classes function of
the same name is very different from the abstract static one in the base
class you want to have. And alone the fact that this could somehow be
possible causes us to have more test code in the engine.
You have to understand the concepts before you can use them. That said
maybe we got to far with static members if not even you understand them.
Besides you can already accomplish what you are aiming for and that is
something i did especially for you, so you were aware of the stuff. You
simply use interfaces, try this:
[EMAIL PROTECTED] /usr/src/PHP_5_2 $ php -r 'interface I {static function F();}
class C implements I {};'
make: `sapi/cli/php' is up to date.
Fatal error: Class C contains 1 abstract method and must therefore be declared
abstract or implement the remaining methods (I::F) in Command line code on line
1
[EMAIL PROTECTED] /usr/src/PHP_5_2 $ php -r 'interface I {static function F();}
class C implements I { static function F() {} };'
make: `sapi/cli/php' is up to date.
best regards
marcus
Saturday, May 20, 2006, 12:56:06 PM, you wrote:
> On Sat, 13 May 2006, Marcus Boerger wrote:
>> the test is wrong. We just added a missing check in 5.2. That means it
>> is a non severe error already in 5.0 and 5.1. Just nobody told us about
>> yet. So please just drop the test case or even better fix it with the
>> expected error message. If this is a real issue for you company we could
>> go with a compromise and make it an E_STRICT in 5.2 and drop the *not bug
>> but feature* in 5.3/6.0. Since E:STRICT was all about notifying ppl about
>> future changes, wasn't it?
> It doesn't really matter if this issue personally affect me or not. The
> thing is that this change is now breaking applications and I am probably
> one of the first to see it cause I keep running CVS all the time. I keep
> saying that there is no good reason NOT to allow "abstract static". The
> only reason that I heard so far from you is that it is not pure OO. So I
> think we should revert the change that makes this a fatal error. I also
> don't even think we should make this an e_Strict or even considering not
> allowing this at all, as there is IMO still nothing wrong by having an
> "abstract static" to make sure implemenations implement this method and
> an interface can not be used.
> regards,
> Derick
>> Friday, May 12, 2006, 12:02:13 PM, you wrote:
>>
>> > derick Fri May 12 10:02:13 2006 UTC
>>
>> > Added files:
>> > /ZendEngine2/tests abstract-static.phpt object-null.phpt
>> > Log:
>> > - Added tests for BC breaking changes.
>> >
>> >
>>
>> > http://cvs.php.net/viewcvs.cgi/ZendEngine2/tests/abstract-static.phpt?view=markup&rev=1.1
>> > Index: ZendEngine2/tests/abstract-static.phpt
>> > +++ ZendEngine2/tests/abstract-static.phpt
>> > --TEST--
>> > Test for abstract static classes
>> > --FILE--
>> > <?php
>> > abstract class ezcDbHandler extends PDO
>> > {
>> > public function __construct( $dbParams, $dsn )
>> > {
>> > $user = null;
>> > $pass = null;
>> > $driverOptions = null;
>> > }
>>
>> > abstract static public function getName();
>>
>> > static public function hasFeature( $feature )
>> > {
>> > return false;
>> > }
>> > }
>> ?>>
>> > DONE
>> > --EXPECT--
>> > DONE
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
