Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103229
To: internals@lists.php.net
Date: Sat, 22 Sep 2018 13:32:05 -0500
Message-ID: <5273905.aE8IdBJUB6@vulcan>
In-Reply-To: <a2b16925-6ccc-4313-d1ca-8032407c379d@gmail.com>
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com> <CADqTB_iV7+S1BoeSACGT3ED76h-MM4Oh4xx_zxXh_GXFSWiqvQ@mail.gmail.com> <a2b16925-6ccc-4313-d1ca-8032407c379d@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart12309140.7u9FmJiHdp"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: larry@garfieldtech.com (Larry Garfield)

--nextPart12309140.7u9FmJiHdp
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

Rasmus: Please be careful when you refer to "you" as wanting or doing 
something.  I had no part in the patch design or implementation beyond saying 
"yay!" a few times on the list/twitter.  "I" don't want a particular engine 
pseudo-type (uninitialized); I honestly don't care about that level of 
implementation detail.  I am only trying to offer suggestions for how to 
tighten the guarantees further without violating the basic facts of how PHP 
works.

On Saturday, September 22, 2018 12:12:48 PM CDT Rowan Collins wrote:
> On 22/09/2018 11:15, Rasmus Schultz wrote:
> >> 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 is literally the same thing - if it can only be set to a given
> > type, it can only BE a given type.
> 
> Consider this analogy: if I build a house with a standard, human-sized
> door, I cannot walk an elephant through that door; however, if the
> elephant was already there, I could build the house around it. So, the
> assertion that "no elephant can get in through that door" is not the
> same as the assertion "there is no elephant inside that house". If
> you're interested in protecting your house from roaming elephants, the
> small door is probably sufficient for your needs; if you want to know
> that when you walk into a house, there is no elephant inside, you need
> other assurances.
> 
> What Larry is pointing out is that Levi and Marco are happy to make the
> door elephant-proof (prevent nulls being assigned to the properties);
> whereas you and I are looking for a stronger guarantee that there will
> never be an elephant inside (that the object will not be in an invalid
> state).

LOL.  Rowan, I love that analogy.  It expresses the problem space very well.

> > I don't think that, and I don't expect that - I'm not suggesting we
> > enforce
> > anything statically, I'm merely suggesting that a constructor needs to
> > satisfy the constraints specified by the class.
> 
> If you read carefully, that's exactly what Larry's proposal below requires.
> 
> >> 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?
> > 
> > In my opinion, this is a solution to the problem we created when we
> > decided
> > every property should internally be annotated with an "initialized"
> > boolean
> > property - you have all this extra state that wasn't part of the
> > specification of the class itself, and now you have to deal with that
> > state.
> > 
> > In my opinion, tracking this extra state *during the constructor call* is
> > acceptable and necessary in a scripting language like PHP - I never
> > asked for static type-checking, I'm merely asking for this check to be
> > built-into the language and performed at run-time when you exit the
> > constructor, e.g. at the last moment where you can feasibly perform
> > this check.
> 
> I'm not sure if you've misunderstood Larry's proposal, or are just
> agreeing with it: the sentence you quote says "add an engine check" and
> "call it on selected actions automatically"; and you ask for it to be
> "built-into the language and performed at run-time"; you mention it
> happening "when you exit the constructor", and just below the part you
> 
> quote, so does he:
> > * on __construct() exit.
> > * on __wakeup() exit.
> > * Possibly other similar checkpoints.
> 
> The key compromise, however, is that this still doesn't guarantee that
> there is no elephant in the house: there will be ways to create an
> object that don't go through the constructor, so won't trigger this
> check; and ways to manipulate an object that will put it into an invalid
> state. Not to mention that inside the constructor, $this will be usable
> as a normal object, unlike in a true 2-phase initialisation system like
> Swift's.
> 
> In short, we will still need runtime errors for attempting to read an
> uninitialized property, but they will be much less likely to happen
> accidentally and show up a long way from their cause.
> 
> 
> I would be interested to hear if there are any use cases that this would
> break - a static factory method can defer as much initialisation as
> needed to the constructor, and cases where the constructor is bypassed
> will also bypass the check.
> 
> Regards,

Yes, Rowan has it exactly.  To continue the analogy, I'm proposing that, once 
the house is built, you take a moment to look inside and say "Holy crap, 
there's an elephant in here!"

In more code terms, this is an extremely common pattern in PHP today (using 
the post-RFC syntax):

class Doer {

  protected Processor $processor;

  public function __construct(Processor $p) {
    $this->processor = $p;
  }
  // ...
}

This code is obviously valid, because while there is a moment at which the 
Doer::$processor value is null/unintialized/not-a-Processor-object, it's a 
short-lived moment and by the time anyone other than the class author cares 
marked as nullable would, in fact, be a worse guarantee.

the constructor it would only blow up in my face, not someone else's.

class DoerOne {
  public Processor $processor;
$d1 = new DoerOne();
$d->processor;
class DoerTwo {
  public function processor() : Processor { return null; }
$d2 = new DoerTwo();
$d2->processor();

Both $d1->processor and $d2->processor() will fail with a TypeError.  In both 
cases it's very clearly and obviously the fault of the Doer class's author. In 
both cases the TypeError happens on access, and I can work back from there to 
figure out where it should have been set.  In both cases my course of action 
It can be done one better, though, by adding an is_there_an_elephpant() check 
at key points.  Effectively, it becomes logically equivalent to:
    if (is_there_an_elephant($this)) { 
     throw new TypeError('Bad, Elephant, no cookie!');
    }
Serializable::unserialize(), or whatever else.  (By analogy, also checking 
that an elephant didn't get in while the window was open.)
  public Address $streetAddress;
}
Because you would at least need a constructor to set $streetAddress to an 
empty Address value.  Which... I am OK with and consider a good trade-off.
PS: It was so, SO hard to write elephant and not elePHPant throughout this 
post... :-)
--nextPart12309140.7u9FmJiHdp
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/GXfY8v0YwFBp4MMKwDFxYXcFAlumiqUACgkQ4MMKwDFx
YXfUVAgAk0PpCc6vWXL/gUYAA+yaG7Qv8zCXMdq4el9Ubqfzs+W0rHq/hET9zn7A
StFTad+qcS6JjWAr3bcDZ5GGT9KtaPHFiRKmBy49JVqQALJpwUCuwzP5JuoUk0wV
qyCXmEzdkX5qYZQeLrqcswa3kQizV0QysWMAtAWDA4HBSy3NGdfUWTrvmvfSYbqz
STWGAzFVH74tB1Yul0pze5OdP0frpTkM6xXWogv9STKHkVGV6hZZ4fOPyq84IIcV
LreO2m0+B+9YX4E3ei1ehRxuczQcmlaY04Zh6UGQwKD1/V7iQP5HmNHptd3ncJmV
vpXuuuEWEnAYSBfncI0yUFWAA338dA==
=LXqJ
-----END PGP SIGNATURE-----

--nextPart12309140.7u9FmJiHdp--