Re: [PHP-DEV] SVN Revisions
On Sat, Apr 3, 2010 at 4:59 AM, Lonny K lon...@gmail.com wrote: I have SVN public access and I'm trying to find the revisions that were made in http://bugs.php.net/bug.php?id=42838 There are no tags on array.c for this bug and the diff link that was posted in the report no longer exists. I cannot see a way to tell what changes were made to what files for this bug. Can someone point me in the right direction on how to look up the diffs? Thanks. http://svn.php.net/viewvc?view=revisionrevision=252899 http://svn.php.net/viewvc?view=revisionrevision=252900 http://svn.php.net/viewvc?view=revisionrevision=252901 http://svn.php.net/viewvc?view=revisionrevision=252902 http://svn.php.net/viewvc?view=revisionrevision=252903 The last commit containts the actual modification. Tyrael
Re: [PHP-DEV] On constructors: BC Break and Class compiler Improvements
hi, On Sat, Apr 3, 2010 at 3:17 AM, Stanislav Malyshev s...@zend.com 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 pierre@gmail.com wrote: hi, On Sat, Apr 3, 2010 at 3:17 AM, Stanislav Malyshev s...@zend.com 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.12 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] Named Parameters
I really doubt named parameters would have much of an impact on anything, but I'd be willing to consider it if a clean implementation was to show up. I think they'd allow to manage complex parameter sets more efficiently than with those $options arrays. But that'd probably require changing the way how parameters are passed, since the stack won't work too good anymore for it. Is the desire for named parameters to only have it for user land function/methods? If so, I am kind of -.5 on this because that would be a little WTF for a new user. If not, then it is a huge undertaking as every internal function and pecl extension would have to be updated to support them. In which case it is a ton of work. I have long ago started passing arrays and doing validation myself, which sucks. I admit, named parameters + scalar type hints would be quite nice and simplify a lot of my code. Brian. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Named Parameters
I don't think thad would require thad much work. we allready have arginfo that does type hinting... Modifieing that to support rewrtiting param order based on reflection Info shouldn't be that hard... The problem however is when an function accepts varargs (usually named ...). if we however bring in strictct-ish naming convention I don't see any immediate problems On Apr 3, 2010 1:02 AM, Stanislav Malyshev s...@zend.com wrote: Hi! I really doubt named parameters would have much of an impact on anything, but I'd be willing t... I think they'd allow to manage complex parameter sets more efficiently than with those $options arrays. But that'd probably require changing the way how parameters are passed, since the stack won't work too good anymore for it. -- 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...
