I agree that this feature should be avoided in userland, but I think
that it would be terrible, if this bugfix would stay this way,
because this breaks backward compatibility -without notification- with
a minor version update both in 5.3 and 5.2 branch.
Tyrael
On Thu, Dec 17, 2009 at 7:37 AM,
Hi,
because this breaks backward compatibility -without notification- with
a minor version update both in 5.3 and 5.2 branch.
well actually the bug was that call_user_func_array() did not trigger
the what you do is deprecated warning.
Calling the function directly would have resulted in a this
As tsarling stated in the bugreport:
http://bugs.php.net/bug.php?id=50394
I'm not complaining about the
warning, which I just added to demonstrate the problem. I'm not
complaining about the new behaviour of zend_call_function() as of PHP
5.3.0, I'm complaining about the lost reference in __call
Contribute in sapi/fpm in order not to bother tony2001
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The PHP development team would like to announce the immediate
availability of PHP 5.2.12. This release focuses on improving the
stability of the PHP 5.2.x branch with over 60 bug fixes, some of which
are security related. All users of PHP 5.2 are encouraged to upgrade to
this release.
Security
Hi guys,
With new namespace inclusions, standards group releasing a common
autoloader, etc, I'm felling the necessity of something.
Basically, I'm suggesting to follow the same way SplFileInfo does,
with a few difference.
Currently, SplFileInfo is include_path aware with anything defined.
Hi!
My suggesting is to add support to include_path just like fopen
already have, which is through a flag. So the prototype would be:
DirectoryIterator::__construct(string $path [, bool $include_path = false]);
Maybe instead of adding this parameter one-by-one to every function
doing
Hi!
Test cases can be found here:http://bugs.php.net/bug.php?id=50394. It
seems to me that a special case would be needed to restore the behaviour
seen in PHP 5.3.0.
I'll check it out, seems to be valid use case, we should find some
solution for that.
There seems to have been no progress
Yes, but stream_resolve_include_path() works only for files and also
it's PHP6 only. =(
On Thu, Dec 17, 2009 at 4:55 PM, Stanislav Malyshev s...@zend.com wrote:
Hi!
My suggesting is to add support to include_path just like fopen
already have, which is through a flag. So the prototype would
On Thu, 2009-12-17 at 18:31 -0200, Guilherme Blanco wrote:
Yes, but stream_resolve_include_path() works only for files and also
it's PHP6 only. =(
Should be quite simple to merge to other branches if anybody really
cares. Doesn't look like anybody cared from the time 5.3 came up until
at least
Stanislav Malyshev wrote:
Tim, could you check if the attached patch solves your problem?
Yes, it works for me, in both the isolated test case and the original MW
bug.
MW's parser test suite shows 4 failing tests in 5.3.1, all fixed with
this patch and no new regressions.
Stefan Esser
Hi!
Yes, it works for me, in both the isolated test case and the original MW
bug.
MW's parser test suite shows 4 failing tests in 5.3.1, all fixed with
this patch and no new regressions.
Great, will commit the patch tomorrow then to all branches.
The underlying functions are declared with
I vote for (A). bind() and bindTo() seem messy to me. However, I
mostly vote for no implicit $this changes in closures (no
javascript-like behaviour), so (A+) approach would be much better than
(C) or (D). (0) case is not my choice, because I really would like to
see $this support in closures
13 matches
Mail list logo
