Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103223
To: internals@lists.php.net
Date: Fri, 21 Sep 2018 16:00:08 -0500
Message-ID: <5016361.XPtX2qLQRi@vulcan>
In-Reply-To: <CADqTB_h4tuyyY-RUX+2+TjybB0LF8=kkkZRfM-JhaVUh+cLxXA@mail.gmail.com>
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com> <fcfeac2f-3fda-5d1c-7e2b-01f10df94e05@lsces.co.uk> <CADqTB_h4tuyyY-RUX+2+TjybB0LF8=kkkZRfM-JhaVUh+cLxXA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3991336.bncjmcWpG4"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: larry@garfieldtech.com (Larry Garfield)

--nextPart3991336.bncjmcWpG4
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Friday, September 21, 2018 10:25:50 AM CDT Rasmus Schultz wrote:
> On Fri, Sep 21, 2018 at 10:24 AM Lester Caine <lester@lsces.co.uk> wrote:
> > Ignoring the debate on uninitialized/null ... not all objects ARE
> > invariant
> 
> hence nullable types.
> 
> > and there are very good reasons for not setting values for
> > everything, but it seems that these types of object are deemed to be
> > 'bad coding' where in fact the simply have elements that yet to be
> > 'initialized' if at all for this instance of the object.
> 
> that's what nullable types are for.
> 
> > The constructor
> > simply creates those elements that need to exit and does nothing with
> > the holders for elements that have yet to be populated ... they stay null.
> 
> hence nullable types.
> 
> the point of using type-hints on the properties of a class is to describe
> the invariant state of that class - if the state of an instance of that
> class is not what the class itself prescribed/promised at the time when you
> return from the constructor, what's the point?
> 
> the only difference between using nullable vs non-nullable property
> type-hints then, is whether you can set them *back* to null after setting
> them to value - but it's okay for them to return from the constructor in
> a "null-like" state?
> 
> this doesn't provide *any* additional guarantees:
> 
> class Foo {
>     public int $bar;
> }
> 
> $foo = new Foo(); // invalid state allowed
> 
> $foo->bar = 123; // valid state
> 
> $foo->bar = null; // invalid state NOT allowed?!
> 
> Have the effects on the null coalesce operator even been considered?
> 
> $bar = $foo->bar ?? "what";
> 
> Is unintialized "null-like enough" or will this trigger an error?
> 
> Extremely confusing.
> 
> Type-annotations are essentially assertions about the state of a program -
> if you can't count on those assertions to be fulfilled (which you
> can't if they're
> not checked at the time of initialization) then they're not useful.
> 
> The bottom line for me is that property type-hints were supposed to make
> my programs more predictable, make the language more reliable.
> 
> Instead, we've introduced a whole new kind of uncertainties, new ways to
> write unpredictable code, a new kind of null that makes the language even
> more unreliable.
> 
> In terms of reliability, it's actually sub-par to hand-written accessors.
> 
> Shorter syntax, reflection support, great - but ultimately at the cost of
> reliability and predictable state.
> 
> For one, what good is reflection, if it tells me I can expect a property to
> be an integer, and it turns out it doesn't have a value after all?
> 
> If you want horrible code with no guarantees, there are plenty of ways to
> do that already - you don't need property type-hints for anything more than
> mere convenience in the first place.

Rasmus, would the "checkpoint validity checks" I suggested in another branch 
of this thread ameliorate your concerns, at least to some degree?  I think 
they're as good as we'd be able to get, given the nature of PHP, but should at 
least cover the most common cases.

--Larry Garfield

--nextPart3991336.bncjmcWpG4
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/GXfY8v0YwFBp4MMKwDFxYXcFAlulW9gACgkQ4MMKwDFx
YXfWJwf8CVtBmh4U8pofsxfIZyg0Rt9Ubf0ZYXEHunM65uDCo4wp4S8PVLBstRLM
9+fzMbyBuFQOC3CvbuhUf70k4tddZ1t2nIw7a+t40R4dfwDlJg1PwZkkYhv/b1HF
12fxXXBZITmYQy+LE7m+awliTiKhjz4NAI4iAvAERqQO88u810o2hJuGbg6x5CKi
S1Yn8tsGcsEq+zvMPvy/GX4NFyV3zVeD3C4rz8LeNTfOR5aeBMkjM9gAFapRJ8Mn
4NS+p+WqkhrLDgFr9TmClmPSPrEeVVnCYexv54s7GQ9/CbdKzVWoIrtelRjUG1qs
+l387QBHv8WKsofIr/b1azUkX/1NVg==
=2Fi0
-----END PGP SIGNATURE-----

--nextPart3991336.bncjmcWpG4--