Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123523
Precedence: bulk
MIME-Version: 1.0
References: <CAOWwgpmbq5VRrZQvUXDsKiNK4r6+bFA4VxnjQ_U=h8T9r0o3DA@mail.gmail.com>
 <ab83af79-0669-47dd-a3cb-ab72327ae174@bastelstu.be> <CAP1Jc13JWVg99AULgzrGXcoCWJtJZGz+nr_VoyUocw8n5n5sfQ@mail.gmail.com>
 <c77832b9-4143-43aa-a71b-eb9d888725e9@app.fastmail.com>
In-Reply-To: <c77832b9-4143-43aa-a71b-eb9d888725e9@app.fastmail.com>
Date: Wed, 5 Jun 2024 20:06:42 +0200
Message-ID: <CAP1Jc12ZwcMS87D2f2r0NwyGJgWxbxEHMa_V7rc8Mjespavt+A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: arnaud.lb@gmail.com (Arnaud Le Blanc)

Hi Larry,

Thank you for the feedback.

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:

```
class C {
     public function __construct() {
        ReflectionLazyObject::makeLazyGhost($this, $this->init(...));
    }
}
```

This one can not be addressed by a newInstance*() method since the
object to be made lazy already exists.

The makeLazyGhost() / makeLazyProxy() methods are the minimal methods
necessary to address all use-cases, but the methods you are suggesting
are a better API most of the time, so we are adding approximately this
to the proposal [1]. We are keeping them in a separate class to not
pollute ReflectionClass.

> 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.

> In which case $object is the proxy, and gets "swapped out" for the return value of the $initializer on first use.

Just to be sure: $object continues to be the proxy instance after the
initializer is called, but it forwards all property accesses to the
return value of the $initializer.

[1] https://news-web.php.net/php.internals/123518

Best Regards,
Arnaud