Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103208
To: internals@lists.php.net
Date: Thu, 20 Sep 2018 10:52:21 -0500
Message-ID: <4983605.CXexPrWP49@vulcan>
In-Reply-To: <CALKiJKoJXxi+khw-BhPf7DCOV+J279UGBupUHBxEKcaj8re85g@mail.gmail.com>
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com> <CAF+90c8He-6M_WAKj7B_+fcgJhos+DPQ07afjmGyoNgx7RzE7g@mail.gmail.com> <CALKiJKoJXxi+khw-BhPf7DCOV+J279UGBupUHBxEKcaj8re85g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2036320.r0KhHcr5ET"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: larry@garfieldtech.com (Larry Garfield)

--nextPart2036320.r0KhHcr5ET
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Thursday, September 20, 2018 6:50:45 AM CDT Rowan Collins wrote:
> On Thu, 20 Sep 2018 at 11:58, Nikita Popov <nikita.ppv@gmail.com> wrote:
> > I do not consider it advisable to require a null initialization as a
> > "first iteration" of the proposal. Regardless of what our intention might
> > be, the effect of such a restriction will not be "I'm not going to type
> > this property for now, because non-nullable types are not supported", it's
> > going to be "I'll give this a nullable type even though it isn't, because
> > that's better than no type at all." Use of nullable types where they are
> > not necessary would be a disastrous outcome of this proposal.
> 
> This, ultimately, is where we disagree. To me, the "non-nullable types"
> this proposal provides are non-nullable in name only, and using them does
> little more than adding a comment saying "I promise this won't be null".
> Encouraging people to use them gives them a false guarantee, and allowing
> them to do so prevents us adding a stricter version of the feature later.
> 
> > To move this discussion forward in a productive direction, we need a
> > concrete, detailed proposal of how enforcement of initialization should
> > work, while being compatible with secondary requirements.
> 
> It feels to me that many of the "secondary requirements" are actually
> separate problems which should be seen as pre-requisites, rather than
> constraints. The lazy initialization pattern seems to be a hack around lack
> of better support for property accessors. The mention of serializers
> needing custom methods of initialisation reminded me of the occasional
> discussion of better replacements for Serializable and JsonSerializable.
> And so on.
> 
> Fixing that list of pre-requisites would obviously take time, which is why
> I wanted to buy that time by releasing initialised-only type hints first,
> and working towards a greater goal.
> 
> However, I've probably beaten this drum long enough. I will hope to be
> wrong, and that making things stricter will still be possible later.
> 
> Regards,

If I may...

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.

That naturally has some coverage holes.  The question then being "is that 
enough?"

I don't think a complete IS enforcement is possible given PHP's nature.  We 
don't enforce at compile time that you cannot call a function with an 
incorrect type; that's enforced at runtime, or by a static analyzer.  That is:

function test(int $a) {}

test($_GET['a']);

Cannot possibly be verified at compile time.  This isn't a compile time check 
either:

$b = 'foo';
test($b);

It's a runtime TypeError, not compile time.

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.  I also get that there's many different pathways by 
which an object could get initialized so there's no one clear validation 
chokepoint.

But... could we have multiple?

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, wouldn't require any new syntax 
beyond a single function, and still lets serialization libraries do their 
thing.

If needed, perhaps there's a way we can let a serialization tool disable that 
check as an opt-out, and then the developer is just on-their-honor to get it 
right.  If it blows up later, well, file a bug with the serialization library.  
In a dynamic runtime language I don't think we'll ever be able to do better 
than that.

Would that be viable as a follow-up to the current RFC?

--Larry Garfield
--nextPart2036320.r0KhHcr5ET
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/GXfY8v0YwFBp4MMKwDFxYXcFAlujwjUACgkQ4MMKwDFx
YXfCUggA5JlO9UZOyl+37XvdxRXXjCVhS0oMdhWt9V9CgYRj2hX0vEL7fcvSG/rW
tIiE+QiwDWuUjM50ueNSFHouRd1KF+W2gaMTiUgcq/ZfLhY5+T87lo8d77eQdpgH
SLV0cEAyKPuBmBRxpVrOBNLQCpJincIr8py2ftP5Ey8J/HdJEWRTji+ivG6/MNYT
/5XmHJIKYEXg7MiojpU91X4B6CSwmMp3MI9ZIEP9WR/P2pZDZmFOGHH+Wt+a+5Pv
5IRYey4yqQ/zKwTLUXQlCLRq2pXXqtbsYQ0q4R+gsr/ZPQQz4/meGNqGPVZOnYUa
Ytd94LIN1iS1wVnIt7DMz4yFXl/KfQ==
=jeiN
-----END PGP SIGNATURE-----

--nextPart2036320.r0KhHcr5ET--