[PHP-DEV] On constructors: BC Break and Class compiler Improvements
Hey Internals,
In our work converting the Zend Framework library to namespaces, we came
across some inconsistencies in constructor namings.
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:
What was once:
class Foo_Bar_Array {}
would become (1 to 1 mapping):
namespace Foo\Bar; class Array {}
but must become
namespace Foo\Bar; class ArrayBar {} (or ArrayObj, ArrayClass, etc)
We can work around these limitations.
With that in mind though, this is the bigger challenge we are faced with...
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]
This worked in 5.2.x.
This worked in 5.3.0.
This stopped working in 5.3.1
Moreover, I do think that this is NOT the correct behavior. While I
know somewhere in the history of PHP we had an engine that preferred
class names as constructor names, but thankfully- those days (one could
only hope) are gone.
IMO, the engine should be backwards compatible as best as possbile in
the 5.x series and should (with the respect of PHP4 tendencies), reward
programmers using proper PHP5 constructs, like __construct.
(While I hate to use the english language as a crutch for the argument..
PHP is after all written in english, ... it is considered a best
practice do have class names as nouns and methods as verbs. Since there
are a lot of cases where the same words are both the noun and verb.. the
verb being the method being acted on in the class, the noun - combined
with the shorter class names due to namespaces, I can see this becoming
a bigger problem as more people embrace namespaces.)
Furthermore, static functions of the same name should not be marked as
constructors by the engine in any situation (is there some BC we are
keeping here? b/c I cannot see the use case.)
Attached is a patch that fixes this behavior (against PHP_5_3). What it
does:
* If __construct is declared before a method of the same name as the
class, you WILL NOT get a notice
* If a method of the same name as the class appears before
__construct(), you WILL get a notice, as the current behavior.
(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)
* 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 am not sure where the current behavior came from. I looks like it got
merged into 5_2_x but then backed out and merged into 5_3_x somewhere
along the line after 5.3.0 was released.
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.
Thanks,
Ralph Schindler
References:
http://bugs.php.net/bug.php?id=35634
http://bugs.php.net/bug.php?id=48215
diff --git a/Zend/zend_compile.c b/Zend/zend_compile.c
index 13b6c55..b7cd7b0 100644
--- a/Zend/zend_compile.c
+++ b/Zend/zend_compile.c
@@ -1285,13 +1285,11 @@ void zend_do_begin_function_declaration(znode
*function_token, znode *function_n
zend_str_tolower_copy(short_class_lcname,
short_class_name, short_class_name_length);
/* Improve after RC: cache the lowercase class name */
- if ((short_class_name_length == name_len) &&
(!memcmp(short_class_lcname, lcname, name_len))) {
- if (CG(active_class_entry)->constructor) {
- zend_error(E_STRICT, "Redefining
already defined constructor for class %s", CG(active_class_entry)->name);
- } else {
+ if ((short_class_name_length == name_len) &&
(!memcmp(short_class_lcname, lcname, name_len)) && ((fn_flags &
ZEND_ACC_STATIC) == 0)) {
+ if (!CG(active_class_entry)->constructor) {
CG(active_class_entry)->constructor =
(zend_function *) CG(active_op_array);
}
- } else if ((name_len ==
sizeof(ZEND_CONSTRUCTOR_FUNC_NAME)-1) && (!memcmp(lcname,
ZEND_CONSTRUCTOR_FUNC_NAME, sizeof(ZEND_CONSTRUC
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
On Sat, Apr 3, 2010 at 4:33 PM, Ralph Schindler wrote:
> 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
>
sorry for resurrecting this thread:
I've had a discussion about this change recently, and I re-read the
whole thread to refresh my memories.
did I miss something, or did we really introduce this BC break based
on a "bogus" report?
I mean, based on Ralph's last email, it seems that the reported
warning was present in all previous versions, and the problem has
nothing to do with namespaces.
btw. I tried to reproduce the problem now, but the E_STRICT only
triggered, if I swapped the order of the __construct and filter
definition, which seems logical, cause if we have the __construct
first, then the classname ctor cannot override that(only the other way
around supported).
I looked around, and I found out that this change was introduced by
Felipe: https://bugs.php.net/bug.php?id=52160
he basically implemented Ralphs original patch/suggestion on his own.
does anybody else thinks that this is a good example what/how not to do things?
ps: Andi mentioned in this thread that we should mark the classname
ctors deprecated with the next version, if we want that, now is the
time.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
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
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
hi, On Thu, Apr 1, 2010 at 9:18 PM, Stanislav Malyshev wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
Hi! 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. I don't feel comfortable with dropping class-named ctor altogether (big BC issue) but dropping it in NS-classes seems to be easier (technically, it's NOT the same name - the real class name is namespace\class) and would solve 99% of the problem without having almost any BC impact. -- 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
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
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
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
On Thu, Apr 1, 2010 at 21:33, Stanislav Malyshev wrote: > Hi! > >> 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. > > I don't feel comfortable with dropping class-named ctor altogether (big BC > issue) but dropping it in NS-classes seems to be easier (technically, it's > NOT the same name - the real class name is namespace\class) and would solve > 99% of the problem without having almost any BC impact. Ouhgawd yes. Please drop support for oldstyle-ctor-in-namespaces. Its a big PITA, and nearly no BC break. I would even consider it a bug fix :] -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
Hi! 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. No, that's a pretty bad band-aid. I'd not be comfortable with such kludge being there, esp. when we are just establishing a new style for namespaced code. 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. Maybe, but that's seems to be too subtle distinction to have, and in the light of the previous issue (not having it be ctor ever) it doesn't matter anyway :) -- 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
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
Hi!
The patch is simple: see attached. Doesn't break any tests except for
ns_063 which specifically tests for this particular case. Any objections
to having this in 5.3?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
Index: zend_compile.c
===
--- zend_compile.c (revision 297301)
+++ zend_compile.c (working copy)
@@ -1270,22 +1270,13 @@
}
}
} else {
- char *short_class_name;
- int short_class_name_length;
- char *short_class_lcname;
-
- if ((short_class_name =
zend_memrchr(CG(active_class_entry)->name, '\\',
CG(active_class_entry)->name_length))) {
- short_class_name_length =
CG(active_class_entry)->name_length - (short_class_name -
CG(active_class_entry)->name) - 1;
- ++short_class_name;
- } else {
- short_class_name = CG(active_class_entry)->name;
- short_class_name_length =
CG(active_class_entry)->name_length;
- }
- short_class_lcname = do_alloca(short_class_name_length
+ 1, use_heap);
- zend_str_tolower_copy(short_class_lcname,
short_class_name, short_class_name_length);
+ char *class_lcname;
+
+ class_lcname =
do_alloca(CG(active_class_entry)->name_length + 1, use_heap);
+ zend_str_tolower_copy(class_lcname,
CG(active_class_entry)->name, CG(active_class_entry)->name_length);
/* Improve after RC: cache the lowercase class name */
- if ((short_class_name_length == name_len) &&
(!memcmp(short_class_lcname, lcname, name_len))) {
+ if ((CG(active_class_entry)->name_length == name_len)
&& (!memcmp(class_lcname, lcname, name_len))) {
if (CG(active_class_entry)->constructor) {
zend_error(E_STRICT, "Redefining
already defined constructor for class %s", CG(active_class_entry)->name);
} else {
@@ -1338,7 +1329,7 @@
} else if (!(fn_flags & ZEND_ACC_STATIC)) {
CG(active_op_array)->fn_flags |=
ZEND_ACC_ALLOW_STATIC;
}
- free_alloca(short_class_lcname, use_heap);
+ free_alloca(class_lcname, use_heap);
}
efree(lcname);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
> -Original Message- > From: Stanislav Malyshev [mailto:s...@zend.com] > Sent: Thursday, April 01, 2010 12:34 PM > To: Pierre Joye > Cc: Ralph Schindler; internals > Subject: Re: [PHP-DEV] On constructors: BC Break and Class compiler > Improvements > > Hi! > > > 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. > > I don't feel comfortable with dropping class-named ctor altogether (big BC > issue) but dropping it in NS-classes seems to be easier (technically, it's NOT > the same name - the real class name is namespace\class) and would solve > 99% of the problem without having almost any BC impact. I agree. I would drop class-named ctors within namespaced classes and possibly in the next major version also do an E_STRICT for these in regular classes to try and get people to convert to __construct(). At a time where there's an increased focus on exposing dynamic services I think the class-named ctors is becoming increasingly problematic. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
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?
--
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
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
Hi! So, I think we've got consensus about not having class-named ctors in namespaced classes in trunk, and unless I hear some screams I'll commit the patch early next week. What about the 5.3? (BTW, I don't see any difference between 5.3.0 and anything later, could anybody point it to me?) We could: 1. Kill the class-named ctors for NS in 5.3 (some BC break, though I have hard time believing anybody used it so far, but who knows) 2. Kill the warning and just ignore the other one if __ctor is there. 3. Leave everything as-is. I kind of favor (1) but want to hear from people here and esp. RMs :) -- 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
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
hi, On Sat, Apr 3, 2010 at 3:17 AM, Stanislav Malyshev wrote: > What about the 5.3? (BTW, I don't see any difference between 5.3.0 and > anything later, could anybody point it to me?) > We could: > 1. Kill the class-named ctors for NS in 5.3 (some BC break, though I have > hard time believing anybody used it so far, but who knows) > 2. Kill the warning and just ignore the other one if __ctor is there. > 3. Leave everything as-is. I'm for 1) as a primary choice, or 3). 2) is just confusing. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
On Sat, Apr 3, 2010 at 13:43, Pierre Joye wrote: > hi, > > On Sat, Apr 3, 2010 at 3:17 AM, Stanislav Malyshev wrote: > >> What about the 5.3? (BTW, I don't see any difference between 5.3.0 and >> anything later, could anybody point it to me?) >> We could: >> 1. Kill the class-named ctors for NS in 5.3 (some BC break, though I have >> hard time believing anybody used it so far, but who knows) >> 2. Kill the warning and just ignore the other one if __ctor is there. >> 3. Leave everything as-is. > > I'm for 1) as a primary choice, or 3). 2) is just confusing. Same here, I consider this a pure bugfix. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
On Thu, 2010-04-01 at 13:06 -0700, Stanislav Malyshev wrote: > Hi! > > The patch is simple: see attached. Doesn't break any tests except for > ns_063 which specifically tests for this particular case. Any objections > to having this in 5.3? Given the feedback on the list I think it's ok. Please make the BC break clear in the NEWS file so I remember to copy it in the announcement. Thanks, johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
Hi! Given the feedback on the list I think it's ok. Please make the BC break clear in the NEWS file so I remember to copy it in the announcement. OK, done. -- 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
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
2010/4/5 Stanislav Malyshev : > Hi! > >> Given the feedback on the list I think it's ok. >> Please make the BC break clear in the NEWS file so I remember to copy it >> in the announcement. > > OK, done. > -- > 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 > > I've just done a quick check on PEAR/packages-all with regard to classes using __construct vs the class name. 818 classes have __construct 1511 use the class name as the constructor 3563 files don't have a constructor I excluded tests, examples and documentation (but some may have crept in). Richard. -- - Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
2010/4/6 Richard Quadling : > I've just done a quick check on PEAR/packages-all with regard to > classes using __construct vs the class name. > > 818 classes have __construct > 1511 use the class name as the constructor > 3563 files don't have a constructor > > I excluded tests, examples and documentation (but some may have crept in). You missed a critical part of this change: When it is inside a Namespace. I very much doubt that many PEAR packages actually use namespaces or even 5.3 only (not badly meant). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
2010/4/6 Richard Quadling : > 2010/4/5 Stanislav Malyshev : >> Hi! >> >>> Given the feedback on the list I think it's ok. >>> Please make the BC break clear in the NEWS file so I remember to copy it >>> in the announcement. >> >> OK, done. >> -- >> 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 >> >> > > I've just done a quick check on PEAR/packages-all with regard to > classes using __construct vs the class name. > > 818 classes have __construct > 1511 use the class name as the constructor > 3563 files don't have a constructor > > I excluded tests, examples and documentation (but some may have crept in). > None of those use namespaces, so there is no break there. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
On Tue, Apr 6, 2010 at 1:32 PM, Hannes Magnusson wrote: > 2010/4/6 Richard Quadling : > > 2010/4/5 Stanislav Malyshev : > >> Hi! > >> > >>> Given the feedback on the list I think it's ok. > >>> Please make the BC break clear in the NEWS file so I remember to copy > it > >>> in the announcement. > >> > >> OK, done. > >> -- > >> 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 > >> > >> > > > > I've just done a quick check on PEAR/packages-all with regard to > > classes using __construct vs the class name. > > > > 818 classes have __construct > > 1511 use the class name as the constructor > > 3563 files don't have a constructor > > > > I excluded tests, examples and documentation (but some may have crept > in). > > > > None of those use namespaces, so there is no break there. > > -Hannes > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > should we check pear2? Tyrael
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
On 6 April 2010 13:52, Ferenc Kovacs wrote: > > > On Tue, Apr 6, 2010 at 1:32 PM, Hannes Magnusson > wrote: >> >> 2010/4/6 Richard Quadling : >> > 2010/4/5 Stanislav Malyshev : >> >> Hi! >> >> >> >>> Given the feedback on the list I think it's ok. >> >>> Please make the BC break clear in the NEWS file so I remember to copy >> >>> it >> >>> in the announcement. >> >> >> >> OK, done. >> >> -- >> >> 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 >> >> >> >> >> > >> > I've just done a quick check on PEAR/packages-all with regard to >> > classes using __construct vs the class name. >> > >> > 818 classes have __construct >> > 1511 use the class name as the constructor >> > 3563 files don't have a constructor >> > >> > I excluded tests, examples and documentation (but some may have crept >> > in). >> > >> >> None of those use namespaces, so there is no break there. >> >> -Hannes >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > should we check pear2? > > Tyrael > Doh. Well at least you all know what you are talking about. Same check on PEAR2... It seems the only places where classnames are used as constructors are in pyrus.phar and sandbox\SimpleChannelServer\pearscs.phar for Pyrus\pyrus.phar : PEAR_Task_Replace_rw Pyrus\pyrus.phar : PEAR_Task_Unixeol_rw Pyrus\pyrus.phar : PEAR_Task_Windowseol_rw Pyrus\pyrus.phar : Net_URL sandbox\SimpleChannelServer\pearscs.phar : PEAR_Task_Replace_rw sandbox\SimpleChannelServer\pearscs.phar : PEAR_Task_Unixeol_rw sandbox\SimpleChannelServer\pearscs.phar : PEAR_Task_Windowseol_rw As these are PEAR classes and don't aren't namespace, the current PEAR2/all looks OK too. Richard. -- - Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
Hi all,
I thought people might be amused to hear that, almost exactly 8 years
after it was proposed, this very reasonable decision caused a lot of
head-scratching yesterday:
From: Stanislav Malyshev
Date: 2010-04-03 1:17:44
So, I think we've got consensus about not having class-named ctors in
namespaced classes in trunk, and unless I hear some screams I'll commit
the patch early next week.
What about the 5.3? (BTW, I don't see any difference between 5.3.0 and
anything later, could anybody point it to me?)
We could:
1. Kill the class-named ctors for NS in 5.3 (some BC break, though I
have hard time believing anybody used it so far, but who knows)
2. Kill the warning and just ignore the other one if __ctor is there.
3. Leave everything as-is.
While migrating an application off a horrifyingly old server, my friend
(who shall remain anonymous to protect the innocent) could not
understand why a private property of a class, initialised in the
constructor, was null when the code ran on the new server. It turns out
that the code in question looked like this:
namespace Foo\Bar;
class Baz {
public function baz() {
// initialisation here
}
}
This code runs correctly *only* on PHP versions from 5.3.0 to 5.3.2
inclusive, because in 5.3.3, Stas's patch mentioned above landed, and
the method is no longer detected as a constructor. It just so happens
that 5.3.2 was the version bundled with Ubuntu 10.04, and somehow the
code remained untested on any other version in all this time.
Out of curiosity, I tracked down why this was changed, and found this
thread. [https://marc.info/?l=php-internals&m=127014823111792] The
awkwardness of allowing both constructor styles was only discovered as
people started to move PEAR-style class names to namespaced ones, so
tweaking it in 5.3.3 made perfect sense. But, as Stas said in the
message quoted above, who knows what features people will take advantage
of, documented or otherwise!
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
