rfc:closures:removal-of-this

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
rfc:closures:removal-of-this [2009/01/26 12:27] – created cseilerrfc:closures:removal-of-this [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Removal of $this in closures ====== ====== Removal of $this in closures ======
- 
-(NOTE THAT THIS IS NOT COMMITTED YET. THIS PAGE IS STILL WORK IN PROGRESS) 
  
 This document describes the changes that were done in order to remove $this support from closures for PHP 5.3 beta1. This has become necessary in order to make sure that when a consensus is found on how to add $this to closures, it will be able to integrate that without BC issues. This document describes the changes that were done in order to remove $this support from closures for PHP 5.3 beta1. This has become necessary in order to make sure that when a consensus is found on how to add $this to closures, it will be able to integrate that without BC issues.
Line 47: Line 45:
 ===== Reflection ===== ===== Reflection =====
  
-TBD.+Reflection was changed a bit in order to make sure Non-OOP-Closures are supported consistently. 
 + 
 +==== getClosure() / getClosureThis() removal ==== 
 + 
 +**Removed** ''ReflectionFunction::getClosure()'' and ''ReflectionFunction::getClosureThis()''. Removal of ''getClosureThis()'' is obvious (no $this stored in closures anymore). However, ''getClosure()'' must also be removed. This is due to the simple fact that in the previous implementation, one could do ''$reflectionMethod->getClosure ($object)'' (ReflectionMethod inherits from ReflectionFunction) and get a Closure that calls the method for the specific object, which means that a closure with bound $this was returned. 
 + 
 +Since allowing that for this special case would perhaps inhibit the possibility of later adding JS-like $this binding to closures at all, it is best to simply remove the method and perhaps later re-add it when the type of implementation is clear. 
 + 
 +==== Modified ReflectionFunction / ReflectionMethod dynamic ==== 
 + 
 +In the original RFC, ReflectionMethod also accepted solely $closure as a parameter to the constructor and implied ''_invoke'' as method name. Those however only gave access to the dynamic invoke method and not the closure method itself. Somewhat later, somebody added the possibility to simply use $closure as parameter for ReflectionFunction. 
 + 
 +This is now consolidated: 
 + 
 +  - ReflectionFunction now accepts $closure as sole parameter 
 +  - ReflectionMethod now does not automatically infer ''_invoke'' as method name for single objects that were passed. 
 + 
 +Thus, a ''new ReflectionFunction($closure)'' has access to the real user-defined closure details and ''new ReflectionMethod($closure, "_invoke")'' has access to the internal auto-generated handler method. 
 + 
 +''new ReflectionMethod ($closure)'' will not work anymore. This is for consistency reasons, since if both ReflectionMethod and ReflectionFunction constructors accepted the closure directly, it would not be clear what ''new ReflectionParameter ($closure, 1)'' would do (now it is clear: use ReflectionFunction as the constructor). 
 + 
 +==== isClosure ==== 
 + 
 +isClosure now detects a closure according to the flags (fn_flags & ZEND_ACC_CLOSURE). 
rfc/closures/removal-of-this.1232972855.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools