Hi Larry and Nicolas! > https://wiki.php.net/rfc/allow_casting_closures_into_single-method_interface_implementations > https://wiki.php.net/rfc/allow-closures-to-declare-interfaces-they-implement > https://wiki.php.net/rfc/structural-typing-for-closures > > What we propose is to instead lean into the interface approach. > Specifically, recall that all closures in PHP are actually implemented as > classes in the engine. That is: > > $f = fn(int $x, int $y): int => $x + $y; > > actually turns into (approximately) this in the engine: > > $f = new class extends \Closure > { > public function __invoke(int $x, int $y): int > { > return $x + $y; > } > }
Just to comment on the technical aspect, I don't think this is accurate. Closures are indeed objects, but they are all instances of the same \Closure class. From what Nikita said in the enum RFC, objects are optimized for size, classes are not. Having different closures implement different interfaces does mean they probably all need their own class, or type checks need to account for closures in some alternative way. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
