Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103219
To: internals@lists.php.net
Date: Fri, 21 Sep 2018 09:11:18 -0500
Message-ID: <2663518.pfEvELVovc@vulcan>
In-Reply-To: <CALKiJKqqbmNZjP-EDH-JC1qX4d2DtbOJZqP_jLcor8vBOO4Lng@mail.gmail.com>
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com> <4983605.CXexPrWP49@vulcan> <CALKiJKqqbmNZjP-EDH-JC1qX4d2DtbOJZqP_jLcor8vBOO4Lng@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1932340.qLdaxArsKR"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: larry@garfieldtech.com (Larry Garfield)

--nextPart1932340.qLdaxArsKR
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Friday, September 21, 2018 4:20:20 AM CDT Rowan Collins wrote:
> On Thu, 20 Sep 2018 at 16:52, Larry Garfield <larry@garfieldtech.com> wrote:
> > I think the distinction here is that one group is arguing for "state of
> > the
> > data assertions" while the RFC as implemented is "setter assertion
> > shorthand".
> > That is, it doesn't assert that a value IS a given type, but that it can
> > only
> > be SET TO a given type.
> > 
> > I don't think a complete IS enforcement is possible given PHP's nature.
> > ...
> > That hasn't brought about the end of the world, so I'm not super worried
> > about
> > imperfect property checks destroying everything.
> > 
> > That said, I totally appreciate the desire as a consumer of an object to
> > know
> > that it's read-type-safe.
> 
> This is a useful distinction, thank you for putting it so clearly.
> 
> Perhaps it depends whether you are looking at the feature as a library
> author, or a library consumer: as an author, you want to protect "your"
> objects from invalid *assignments*, inside and outside the library; as a
> consumer, you want assurance that you can *use* the object in a particular
> way. The current implementation provides a good tool for the author, but
> falls short for the consumer.

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.

In either case, if I fail to initialize a variable the only code that would be 
impacted is... my own, usually in the same class (or occasionally in a 
subclass).  Finding the bug then is pretty straightforward, and it's my own 
damned fault, but therefore easy to fix.

In my experience at least, most of the modern code I see in the wild is the 
same way.  That means the potential impact of stray undefined properties 
roaming around the code base is really small.  Even vaguely reasonably 
structured code already avoids this problem.  I can't think of anything I've 
written in the last few years that wouldn't work this way, even with a 
constructor-exit-validation check, without any modification at all.

Naturally if someone is using a lot of public properties in their code the 
potential for "undefined" bugs increases.  That seems rather uncommon in my 
world, though.

> > To wit, could we add an engine check to scan an object and make sure its
> > objects are all type valid right-now (viz, nothing is unitialized), and
> > then
> > call it on selected actions automatically and allow users to call it at
> > arbitrary times if they are doing more esoteric things?
> > 
> > I'm thinking:
> > 
> > * on __construct() exit.
> > * on __wakeup() exit.
> > * Possibly other similar checkpoints.
> > * When a user calls is_fully_initialized($obj); (or something)
> > 
> > is_fully_initialized() would return bool. The other checkpoints would
> > throw a
> > TypeError.
> > 
> > 
> > That would layer on top of the current RFC cleanly, would give us the
> > read-
> > assurance that we'd like in the 95% case
> 
> I think this is a really sensible approach: as you say, it may never be
> possible to assert the invariant in every case, so checking the most common
> scenarios may be the pragmatic thing to do.
> 
> Conveniently, treating it as an occasional assertion, rather than a strict
> invariant, means we can keep the unset() lazy-initialization hack; it's
> still an odd feature IMO, but probably not all that likely to be triggered
> by mistake.
> 
> Regards,

Another benefit, since it would, I think, boil down to a series of isset() 
calls implemented in C land the performance impact is probably not measurable.  
(Obviously we'd need to measure that... :-) )

--Larry Garfield
--nextPart1932340.qLdaxArsKR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAluk/AYACgkQ4MMKwDFx
YXfLOgf+LX7xVCN1RC/dUUcbFz2cn6Q1eECI5WrP/NsLSd8I3Y1V9fBqgx+eU+aK
zVy1MObbF/LhGNg+IAO0ZjOjNQUsw1/dYOuCL/KHJSCvxBeHKY++tMTgfzclwWeN
CXDs0mfg9nOznYvz5437ODCMWCHWJPD8XFoj/dB4twA7nQ0QOwlUHGwSJRgCyH3A
WlfG8Lwjnl2R0532eQq/iwhiHV+hMsHJXxIxIpB6M+LzoefhLUim40TyCTNDSOwO
hkAI7Sy5dDXF9G/PWtNzhcHcerhiA/A560n5/vs7Jl5Po18yFPUwHb63NXLOwdIv
kUqoIP4A9N0PniGbRJ6KMZsojbOeLA==
=BT4Z
-----END PGP SIGNATURE-----

--nextPart1932340.qLdaxArsKR--