On Mon, 7 Aug 2006 10:14:01 +0200
[EMAIL PROTECTED] (Marcus Boerger) wrote:
> Hello Andi,
Hello,
> 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.
I'm not sure to understand this statement. Do you mean that every
E_STRICT error must be solved to do not bring the engines in an unknown
state?
> 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.
The aim was to give OO users the tools they need, not to remove why our
users base is so large (even *before* we added all these OO features),
the freedom of choices.
> 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.
Three people?
> <thinking>Oh thinking and documenting is forbidden - i see</thinking>
PHP thinks for me now, and if it is about documenting, then I don't any
interfaces and all the other additions, I can document everything.
-- Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
