Marcus,
A few points:
- There's nothing wrong about being lazy, especially as PHP's main
selling point is that it's easy to use (or in other words - also
suitable for people who have better things to do than mess with the language).
- I can assure you that there are a hell of a lot more than 3 people
who are 'lazy' in the PHP arena, and prefer not to be bothered with
what they consider to be noise. Whether they're the majority or the
minority is debatable, but there are definitely many many thousands of them.
- I think it makes perfect sense, from an end user perspective, for
built-in classes to behave slightly differently from userland
classes. Many (most?) users won't make the distinction between a
built-in class and a language feature, it is a language feature as
far as they're concerned, and it makes sense that it will have its
own semantics.
- I don't think we need to tag all of the built-in methods with this
flag, it's absolutely not necessary at the engine level. We should
probably only tag those methods which are callbacks, which would
misbehave if they don't adhere to the same signature as the method
they're overriding. Maybe there's another general case, but for the
most part, most internal methods don't need that flag in my opinion.
And one final note - I think it would greatly help if you realized
that there are many people out there for which the additional OO
features in PHP are not a blessing but some sort of a curse, since it
makes their simple language more complex than it used to be. Nothing
you (or anybody else) is going to say is going to change that, since
it's a fact that today there's a lot more you have to learn and a lot
more concepts you have to be aware of in order to understand PHP
code. Is it worth it? Probably, since it comes with added benefits
- but does it mean we should forget about the price we're paying and
think time and time again about the simplicity
consequences? Absolutely not. Often, that means we'll have to make
compromises, or even not implement certain features at all.
Zeev
At 11:14 07/08/2006, Marcus Boerger wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
