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
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: Redefini
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
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.
>
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..
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 docum
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
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 -
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
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
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 i
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 an
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?)
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 c
> -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
>
> H
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
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
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 altog
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.
[inlin
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 easie
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
>
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 real
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 for
23 matches
Mail list logo
