Hi
Thank you Larry for your email. Your suggested API is basically what I
also had in mind after Arnaud's clarification.
On 6/5/24 20:06, Arnaud Le Blanc wrote:
I think you got the two strategies right. However, there is a use-case
in which an object manages its own laziness by making itself lazy:
What is the corresponding real-world use case for that? When would I
want to create an object that makes itself lazy?
FWIW: If I understand it right, this use case would be supported by
Larry's proposed API by writing a named constructor:
class C {
private function __construct($foo, $bar) { }
public static function lazyNew(...$args) {
$r = new ReflectionClass(self::class);
return $r->newInstanceWithLazyConstructor(fn ($o) =>
$o->__construct(...$args));
}
}
It also suggests that perhaps the function should be using $this, not $foo, as
it's running within the context of the object (I presume? Can it call private
methods? I assume so since it can set private properties.)
The function is not running in the context of the object. It can only
access private members via Reflection or if the closure was bound to
the right scope by the user. This should not be an issue when the
initializer just calls a public constructor.
Please clarify the interaction with visibility in the RFC.
Best regards
Tim Düsterhus
