Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47716
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain smashlabs.com from 67.15.58.61 cause and error)
Message-ID: <4BB4F556.6090708@smashlabs.com>
Date: Thu, 01 Apr 2010 14:34:46 -0500
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: internals <internals@lists.php.net>
References: <4BB4EC2F.1020502@smashlabs.com> <4BB4F16B.7020402@zend.com>
In-Reply-To: <4BB4F16B.7020402@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
From: ralph@smashlabs.com (Ralph Schindler)

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