Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102917
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.19 as permitted sender)
To: Rowan Collins <rowan.collins@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <8916EC21-D368-40F8-9ABD-CE0C04A73539@gmail.com>
 <CADyq6sKNPQeqRtLOO5bpH+hM=ngwt7fn3p2srN0qEO7i3xax=A@mail.gmail.com>
 <CALKiJKroFzn1C6x1xGO1MtVJ9h-ebwXjSS9NGa9kmghT-iyiQg@mail.gmail.com>
 <1832302.prXWr4o048@vulcan>
 <CALKiJKoZh6WE1yO-OXvLtyKhS_O4t8c8uL+NKkpQSLQfyPjrqg@mail.gmail.com>
Message-ID: <c2ecadcb-0c29-6cdc-fdde-e33bd53d5a79@gmx.de>
Date: Thu, 19 Jul 2018 16:20:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CALKiJKoZh6WE1yO-OXvLtyKhS_O4t8c8uL+NKkpQSLQfyPjrqg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Non-nullable properties
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 19.07.2018 at 15:41, Rowan Collins wrote:

> On 16 July 2018 at 17:09, Larry Garfield <larry@garfieldtech.com> wrote:
> 
>> class Foo {
>>
>>   protected Bar $b;
>>
>>   // This runs before __construct, is not inherited, and cannot
>>   // ever be skipped.  If this method exits and any property is still
>>   // value-less, TypeError immediately.
>>   protected function __init() {
>>     $this->b = new Bar();
>>   }
>>
>>   public function __construct() {
>>     Behaves as it always has.
>>   }
>> }
>>
>> That's similar to the "initialize" flag inside the constructor, but splits
>> it
>> off to a separate method that is devoted to just that purpose; it
>> therefore
>> has no parameters, ever, and if you want to initialize an object property
>> based on a constructor argument then you must either make it explicitly
>> nullable or initialize it to a dummy value first.
> 
> The extra method certainly feels more "PHP-like" than an extra keyword, but
> as you say, calling it automatically makes it awkward to initialise based
> on any kind of input.
> 
> A couple of variations on the theme:
> 
> a) __init() takes the same arguments as __construct(), but is called first.
> This might be rather confusing, though - we could insist on the signatures
> matching, but people might be surprised that their constructor parameters
> are passed to their object twice in different methods.
> 
> b) __init() is not called automatically, but has to be called manually,
> with whatever parameters you want, as the first line of __construct(). This
> feels a bit weird, because no other method name causes special behaviour
> when called manually. On the other hand, it allows it to be called in other
> situations, such as unserialize, which by-pass the constructor.
> 
> A compromise system which doesn't need new keywords or magic would be to
> combine the current error-on-access behaviour with a check at the end of
> the constructor.
> 
> So:
> 
> = as soon as the constructor starts, $this is available as normal
> = accessing non-nullable properties of $this before initialising them would
> give an error (as in the current proposal)
> + when the constructor returns, the engine checks that all non-nullable
> properties have been correctly initialised, and immediately throws an error
> if they have not
> + Serializable#unserialize() could run the same check, since it is
> effectively a constructor
> = ReflectionClass#newInstanceWithoutConstructor could just allow the
> incomplete object, since such an object is not likely to work smoothly
> anyway
> 
> Since $this can be passed to other functions and methods by the
> constructor, there is still a chance of code outside the class seeing an
> incomplete object and getting errors, but the distance between cause and
> effect (which is my main objection to the current proposal) is massively
> reduced.

It seems to me that either of these proposals would render the lazy
initialization pattern outlined in the “Overloaded Properties”
section[1] invalid.

[1] <https://wiki.php.net/rfc/typed_properties_v2#overloaded_properties>

-- 
Christoph M. Becker