On Sun, 02 Sep 2012 01:04:10 +0200, Stas Malyshev <smalys...@sugarcrm.com> wrote:

SPL is not a part of basic language syntax. There are no SPL keywords
and no SPL classes used unless you explicitly instantiate those classes.
So SPL is different.

End users do not see nor buy the difference between what is Zend/ or
what is ext/spl (or other) and can't be disabled, like SPL.

Of course they'd see it. Here it goes again: "There are no SPL keywords
 and no SPL classes used unless you explicitly instantiate those
classes". You can not just write some plain PHP syntax and end up having
SPL class. If you use SPL class, you must do "new SplSomeClass" or
something similar. It has nothing to do with disabling.

This is thoroughly unconvincing. Let me see if I got this:

Users do not expect exceptions in the core. They distinguish the core from the rest because the core is what they interact it when they "use only PHP syntax" (itself an odd statement, but let's let it pass).

This argument has at least these shortcomings:

* If users do not expect exceptions in the core, they are mistaken. There are indeed exceptions in the core. See ZEND_FE_RESET and zend_interfaces.c. Of course, no evidence has been provided one way or another.

* Most ext/spl classes are not prefixed. If you ask the average PHP developer to tell between Iterator, IteratorAggregate, RecursiveIterator, ArrayAccess and Serializable, which are core and which are ext/spl, I doubt many would get the answer right. Not that they should care.

* In fact, if there is a unifying theme in the usage of exceptions in PHP, is that exceptions are used when OOP interfaces are involved (see Zend interfaces, SPL, DateTime and PDO -- though optional there). The core vs. non-core argument only looks attractive because there are few built-in classes in the core.

To be sure, there's one important distinction between core and ext/spl. ext/spl should depend on core, not the other way around. Which has little relevance for this discussion.

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to