Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103220
MIME-Version: 1.0
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com>
 <4983605.CXexPrWP49@vulcan> <CALKiJKqqbmNZjP-EDH-JC1qX4d2DtbOJZqP_jLcor8vBOO4Lng@mail.gmail.com>
 <2663518.pfEvELVovc@vulcan>
In-Reply-To: <2663518.pfEvELVovc@vulcan>
Date: Fri, 21 Sep 2018 15:50:54 +0100
Message-ID: <CALKiJKoFdKtOGtqDzRCCTwFBODZ8XUzUfPdzHuQ7mDuAzKzqUw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e75cb3057662c415"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000e75cb3057662c415
Content-Type: text/plain; charset="UTF-8"

On Fri, 21 Sep 2018 at 15:11, Larry Garfield <larry@garfieldtech.com> wrote:

> Perhaps another disconnect here is that, in practice, the consumer of an
> object property is, in my experience, almost always "me".  I almost never
> have
> public properties on my objects.  On the rare occasion I do, it's for a
> "struct object" I'm using internally as a more self-documenting and memory
> efficient alternative to a nested associative array.


My impression is that people will be encouraged by this feature to
implement more value objects with public properties, where they currently
have getters and setters doing nothing but type checks; and thus more code
will be exposed to uninitialized properties if there is a bug in a
constructor.

Indeed, it's arguable that if all properties were private, there would be
no need to enforce type hints all, since analysis of where they were set
would be trivial.

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000e75cb3057662c415--