Hello !
In bug report http://bugs.php.net/bug.php?id=51326, johannes say that
the next major version of PHP (5.4 / 6.0) will have better oo support
for closure.
Is there any RFC about that available ?
And where are the patches ?
Best regards,
Fred.
--
PHP Internals - PHP Runtime Development
There is also the improvement on the scope of $this:
*http://tinyurl.com/ybqyskx*
Frederic Hardy wrote:
Hello !
In bug report http://bugs.php.net/bug.php?id=51326, johannes say that
the next major version of PHP (5.4 / 6.0) will have better oo support
for closure.
Is there any RFC about
Hi,
Take a look at the code example [1].
Why not giving programmers the possibility to init their scripts with
a call, that tells exactly what data should be taken - like GET userid
INT and GET password MIXED, or just POST domainid INT, or something
like that.
If there's data transmitted, the
On 08.04.2010, at 12:48, daniel zulla wrote:
Hi,
Take a look at the code example [1].
Why not giving programmers the possibility to init their scripts with
a call, that tells exactly what data should be taken - like GET userid
INT and GET password MIXED, or just POST domainid INT, or
I'm not sure if this is a bug, an oversight, or something that is known
and deemed not-worth-fixing, so I thought I would ask here first.
Consider the SPL_Types extension. This extension introduces some
classes that override assignment in order to do some type-checked
autoboxing:
$int =
Hey Everyone
I've put together a simple RFC[1] that lists features thats been
deprecated in 5.3, someone of them which I propose we remove in the
next version of PHP, depending on the version number. Most of the
features, which is listed below are taken from the old 6.0 NEWS[2]
file, and items
Hi!
asp_tags
- Proposed to be removed aswell, Tony had a patch for this[5].
IIRC last time we discussed it there was no solid reason found to do it
and some reasons not to. Could you remind why would it be useful to do it?
Class named constructors
- A feature thats been marked in the
Hi,
I wrote a test and a fix for this bug a few days ago. Both patches are
included in the ticket. I do realize that Dmitry, the one assigned the bug
might be busy and that the patch might take a while to get reviewed.
However, I want to make sure that there is no administrative step on my part
