So does this mean that the patch would be included even in its somewhat broken
state? Just don't allow it in loops or warn when it is or access to outside
scope variables.
I need to get VLD working on Windows to see what the fuss is all about. I
thought everything is compiled to oplines, if that is so, then why not back up
to the previous function space, keep the scope when you encounter an inside
function, which should be assumed to be a closure.
If you compile and store the closure function in top level userspace, then it
should be able to be accessed at runtime.
function test()
{
$f = function () { return 0; }
return $f;
}
$closure = test();
$closure();
Err, Pseudo-oplines, but since I don't exactly know anything about PHP opcodes,
I'm just pulling this stuff out of my ass.
CREATE_FUNCTION test
CREATE_FUNCTION zend_anon_0
RET_VAL 0
END_FUNCTION
END_FUNCTION
CALL 'test'
ASSIGN $0, $valuefunction
(I have to admit that I'm not that far in Assembler for procedures (yes, I'm a
kook, but I can change baby, just give me another chance) and I apologize, but
thanks for reading this far!)
CALL $0
In which at run time the following can be replaced with:
CREATE_FUNCTION 'zend_anon_0'
RET_VAL 0
END_FUNCTION
CREATE_FUNCTION 'test'
RET_CLOSURE 'zend_anon_0'
END_FUNCTION
CALL 'test'
CALL 'zend_anon_0'
I do recall that parameters are passed somewhere. Eh. Aside from getting the
Oplines, opcodes, as well as the instruction names wrong, and pretty much
everything. What else is wrong with this?
But if that's the best that can be done with the resources available,
I think it would be a good compromise.
Especially as it leaves open the possiblity of someday nailing down a
complete clear definition of what the scoping rules turn out to be,
with room for experimentation in the meantime without violating BC.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
