Hey Stas,
The other option here is to simply go back to the behavior in 5.3.0
where no notice is raised at all. That is easy to accomplish (its just
removing the notice inside the first if block of
zend_do_begin_function_declaration(). It would also maintain
consistency with 5.2.x.
[inline response]
* 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?
Consider this idea a band-aid. It would basically allow for us to move
forward in the 5.x branch with backwards compatibility until 6.x drops
and PHP4 style constructors can go away forever.
* 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 :)
Two notes here:
1) I think that is a *fantastic idea* to drop PHP4 constructors from
namespaced code. I'd be all for it! I think that is fairly easy
behavior to achieve.
2) Another use case that is currently stifled by the current behavior:
namespace Foo\Bar;
class Filter {
public static function filter() {}
}
In general, it seems like method names of the same as the class name
should *NOT* be marked as the class constructor if they are static.
The above produces this E_FATAL:
PHP Fatal error: Constructor Foo\Bar\Filter::filter() cannot be
static in [snip]
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 :)
Yeah, thats a bigger issue in an of itself that's better to be addressed
in the far-off-but-hopefully-not-too-distant php6.
- Ralph Schindler
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
