Hello Andi,
Sunday, August 6, 2006, 10:56:18 PM, you wrote:
> 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.
We might want to do C) for 5.2 already to avoid yet another BC issue
or even more discussions in the future. We have enough discussions on
E_STRICT already now. Because it's fate is to undecided, people are
getting confused on this one.
Regarding B) you might want to have php_error_docref handle that high
level in php_error_docref*() and zend_error().
Now regarding A) the strict mode is an absolute requirement for the stuff
the engine handles. However this results in a lot of confusion. Why are
suddenly a few things strict and error out while others don't. And why
allow something that is absolutley wrong. It does not only violate any
theory on OOP but also all we aimed for with PHP 5. Is it enough that
like three people are to lazy to type a few keystrokes and have to look
up the baseclass which might involve reading the documentation.
<thinking>Oh thinking and documenting is forbidden - i see</thinking>
best regards
marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
