Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103235
To: internals@lists.php.net
Date: Sun, 23 Sep 2018 11:09:39 -0500
Message-ID: <1681263.Ri4PIu1jiQ@vulcan>
In-Reply-To: <CADqTB_h1oWExsgmxR6RHbX1Eew2YiQTGjR2PgJc=4uW4qAJHYw@mail.gmail.com>
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com> <D23FE5D3-4C11-424A-9837-F5F838D4CDBC@gmail.com> <CADqTB_h1oWExsgmxR6RHbX1Eew2YiQTGjR2PgJc=4uW4qAJHYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1981976.1rSFtVvOgG"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: larry@garfieldtech.com (Larry Garfield)

--nextPart1981976.1rSFtVvOgG
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Sunday, September 23, 2018 1:18:02 AM CDT Rasmus Schultz wrote:
> > That is the entire point of the elephant analogy: that knowing what can
> 
> get in doesn't necessarily mean knowing what is already inside - BUT,
> knowing what can get in may still useful in itself.
> 
> I understood that, and I disagree - just knowing what can get in is not
> useful or interesting in itself. It's not even a new language feature - you
> can already achieve the same with a simple setter. It's just new syntax.
> 
> The only reason it's interesting to control what can get inside with type
> hints, is to enable the language to do something new - something it
> couldn't already do, which is to guarantee that the type enforces it's own
> state specification.
> 
> I understood the analogy, and I don't agree.

You previously listed this as an example of problematic code:

class Test {
    public string $b;
}

$b = 'foo';
$test = new Test();

And I agree, that's problematic, just not as show-stopping as you seem to feel 
it is.  Which is why I suggested adding a post-constructor-validation-check, 
in which case the above code would fail with a TypeError on the last line (new 
Test()), since it reached the end of the constructor without fulfilling its 
property validation requirements.  Because that is, in the end, the best we 
can do without radical changes to how the language works.

Basically, we have 3 options:

1) Object properties may not ever be type hinted except as nullable, which is 
kinda useless.

2) Object properties may be type hinted but a sloppy class author may still 
leave them undefined/null if they're careless, which is the RFC today.  (How 
much of a problem you think this is depends on how sloppy you expect class 
authors to be.)

3) Object properties may be type hinted and the class author has until the end 
of the constructor to make sure they're fulfilled, otherwise TypeError on the 
spot (what I'm proposing).

If option 3 is insufficient, please explain why.  You have yet to comment on 
that, just say the current RFC is awful.  If adding the extra checks is 
insufficient, offer an alternative.  I cannot think of one that doesn't 
involve adopting Rust's type system.  (Which would be kinda cool, but also 
horribly impractical to do within the next decade.)

--Larry Garfield
--nextPart1981976.1rSFtVvOgG
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/GXfY8v0YwFBp4MMKwDFxYXcFAlunusMACgkQ4MMKwDFx
YXdiMAf+MhuZbarEikpA7jTSFp/lLq6l5IZLwBfq/IF6R+ycQDiJOU/m3KiYDua7
93ct5AXtUViWQju63RmbiSqT84ZYPUZlcxLVzJT6PfzZmedxAqhlgoaZR7YllqGc
h4CPyyMYpZbxARSjT8qqky7XNmUiQxLzhi6rZPUwTUMft9L/5U+L6DNgjE7EvEu/
oEf+J3pN15mS9o+cOV72XbIiTAzBG/K6Ug2TM98Bm3eWUkBWAyFe2WazyOskFL7d
R3iWFCziNvREVJVzdapTG8cFsZnJaHPfe2oIZ9bT7oWZgevs+FeuedcSYlwSVJ5J
vKNOOSqHebnU7E64UYcZ3nNOG7k0lw==
=kZwa
-----END PGP SIGNATURE-----

--nextPart1981976.1rSFtVvOgG--