Hi!
Clearly, with namespace support making class names shorter, we come back
full circle where some class names collide with reserved words, thus we
are forced to become creative with class names:
That might go away if we agreed to give up on case-insensitive class
names (which btw don't really work that well with frameworks anyway -
try autoloading class in wrong case from case-sensitive filesystem).
That would also make the engine simpler (and faster :) in a couple of
places. But of course at cost of some BC pain.
The following seems, to me, to be a BC break with regards to notices and
E_STRICT usage:
namespace Foo\Bar;
class Filter {
public function __construct() { /* construct stuff */ }
public function filter($value) { /* return filtered */ }
}
Produces:
PHP Strict Standards: Redefining already defined constructor for
class Zend\Filter\Filter in [snip file] on line [snip line]
Hmm... Interesting issue. Without namespaces filter() obviously would be
Filter's ctor, as class names aren't case sensitive now, remember? But
with namespaces it gets tricky. Can we say filter() is still the ctor,
and if not - we've got a problem of not being able to define a named
ctor for a namespaced class. I'd say "good riddance" but some may disagree.
* If __construct is declared before a method of the same name as the
class, you WILL NOT get a notice
I don't like this. The behavior should not depend on other methods being
defined. What if you refactored the class and moved the ctor out to the
parent - and the you get a nasty surprise of filter() suddenly becoming
new ctor?
(The idea here is that if you define __construct before anything else,
as most people do, it will take priority and allow you to use the method
name of the class name below that as normal)
In general, I actively do not like the idea of language behavior
depending on the order of methods in the class. It's a bad idea. Code
changes, and keeping track of this would be a nightmare.
* Static methods of the same name as the class will NOT be marked as
constructors (they currently are). This might invalidate the check done
inside zend_do_end_class_declaration() that checks to see if the
constructor is static. (Perhaps that first check becomes dead code?)
I would propose to have "class-named ctor" apply only to non-namespaced
classes. Yes, that'd mean when you namespace a class you'd have to
convert class-named ctor to __ctor, but if you want namespaces, you'd
have to abandon your php 4 habits :)
In any case, considering we are not gonna get a context aware parser
that will allow us to use reserved words for symbols like classes and
functions, it would be nice to not have this seemingly artificial
limitation on having method names that do not match the class name.
Having parser that'd allow class named "array" is probably too hard, and
there's a couple of cases (like function args) where it would plain just
not work. Having class names Array is possible if we give up
case-insensitivity (and I'd like to see that happen sometime - PHP is
not a kid anymore :), but that'd probably require some consensus and RFC :)
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
