Hey,
Coming into this a bit late (took me a while to read the gazillion emails on
the topic.
First of all, I agree that we can find some middle ground which should make
everyone happy.
I don't think that making interfaces have additional semantics is the way to
go though. I personally don't think that signature semantics of interfaces
should be different from abstract classes nor class themselves. So I'd
prefer to shelf any ideas that build on top of that.
What I do think we can do is inline with some suggestion made here,
especially Zeev's:
A) Allow explicitly marking methods as strict (triggering E_ERROR). Not sure
yet if we want this for user-land but in the least, we can do it for
internal classes and at some point expose this to user-land if we feel it's
needed.
B) Emit E_STRICT if this isn't matched. Note: Dmitry and I have discovered
that some of these recurring E_STRICT
messages can cause serious performance problems. We'd have to experiment
with checking the error_reporting mask with an if() {} before we actuall
call zend_error() (or maybe have a zend_error_inline() which is for engine
stuff which could be called often). Everytime we add such additional
behavior it will add a tiny slow down. If done correctly with an if() it's
negligble on its own, but be aware, over time 10 if() statements end up
slowing things down.
C) I think splitting up E_STRICT into E_STRICT/E_DEPRECATED is a good idea.
E_STRICT was supposed to be pedantic mode, i.e. just enforcing best
practices. E_DEPRECATED would then give warning of things we truly are
thinking of nuking. Lots of stuff which is E_STRICT today falls under best
practices and not deprecated features.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
