On constructors: BC Break and Class compiler Improvements View as Markdown

hi,

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.

Well, I think the question here is more about dropping old style
constructor that case sensitive functions/methods name. I'm in favour
of dropping in php-next.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

Stanislav Malyshev wrote:

Hi!

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]

I just checked - this code produces the same warning in 5.2 (without the
namespace of course), and in 5.3.0. So I don't see what changed in 5.3.1
exactly?

Nothing changed, you are right, the behavior is there in all these versions.

My PHP's for 5.3.0 and 5.3.1&2 have different default values for
error_reporting, and since changing to E_STRICT at runtime is too late
(file already compiled with error_reporting of php.ini), I was not
triggering the code properly.

(My 5.3.0 was shipped from apple, as was their php.ini which the default
error_reporting value is E_ALL & ~E_NOTICE & ~E_DEPRECATED, not the
newly recommended php.ini-development value of E_ALL | E_STRICT. Also,
in 5.2 series, the PHP group never recommended to use E_STRICT in the
php.ini, another reason the code was not triggered in my testing.)

-ralph