Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87126
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.220.51 as permitted sender)
Message-ID: <55A30267.10204@lerdorf.com>
Date: Sun, 12 Jul 2015 17:12:23 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
References: <CAObuZdsA6T7uTCPignr_9g1bAbd83hsTrv9mAg7jU=oY96C9+Q@mail.gmail.com> <CALW=WECOo-JDWgHbmy=eUAVWCxt-0m_9sP-JeXe1hc0SokH37w@mail.gmail.com> <55A16375.4000707@php.net> <CAOsHV+sV2p7aBWOro=D5+xV+LZvNrt4Au3R3SqcJDy9qdPj8ig@mail.gmail.com> <55A220D8.3090004@gmail.com> <CAOsHV+tEjzAnG4ygRj1=0JgO4ps4AbWFQVHFex0+GuY44rdZbA@mail.gmail.com> <55A2C1F2.8000301@garfieldtech.com>
In-Reply-To: <55A2C1F2.8000301@garfieldtech.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="VGbVC48uCTm2ibs5GAuejCrgwEgwEeoR4"
Subject: Re: [PHP-DEV] PHP7 and types
From: rasmus@lerdorf.com (Rasmus Lerdorf)

--VGbVC48uCTm2ibs5GAuejCrgwEgwEeoR4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 07/12/2015 12:37 PM, Larry Garfield wrote:
> I don't know why we're even talking about IDEs here.  IDE
> auto-completion isn't the point, anymore than it was the point for
> scalar type hints or return type hints.  It's about the language doing
> type checking for you and static analysis, so that the language can fin=
d
> bugs for you. Eg:
>=20
> class Foo {
>   public Bar $bar;
> }
>=20
> $f =3D new Foo();
> $f->bar =3D new Baz(); // This line is clearly wrong and the compiler c=
an
> check it for you.
>=20
> That's what the benefit would be.  Easier IDE auto-completion is a nice=

> extra, but not the main goal.
>=20
> +1 from me in 7.1.

I am not sure static analysis is a great argument for it either. A
static analyzer can read the docblock really easily too since it is part
of the AST node for the property. In fact I just wrote one. Feeding it
your code example:

% cat -n test.php
     1	<?php
     2	class Baz { }
     3	class Foo {
     4		/** @var Bar $bar */
     5		public $bar;
     6	}
     7=09
     8	$f =3D new Foo();
     9	$f->bar =3D new Baz();

% ./phan test.php
Files scanned: 1
Time:		0.11s
Classes:	2
Methods:	0
Functions:	0
Closures:	0
Traits:		0
Conditionals:	0
Issues found:	1

test.php:9 TypeError property is declared to be bar but was assigned Baz

Plus, without union types, doc-comment typing is much more convenient
when it comes to running a static analyzer on real-world code since
limiting everything to a single type is often impractical. If you grep
through existing code in the wirld, you will find a ton of Bar|bool,
Bar|Baz|bool|null, etc.

I'm not against the idea, but it is quite different from the existing
type checking since this is a type check that would need to be done on
every assignment for it to make any sense at all and not just at call
boundaries like the existing ones. It may not be feasible to do in an
efficient manner. A static analyzer can get away with catching 95%. A
core language feature can't. Having to do these the type check on
assignment will likely require some significant changes to the engine.

-Rasmus


--VGbVC48uCTm2ibs5GAuejCrgwEgwEeoR4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlWjAmcACgkQlxayKTuqOuBxowCfW4/ca0AMYYvs9ixNtv4toU3t
RX4An0FfIhV0wWkL/vNwDIcLNUZOSytD
=iwij
-----END PGP SIGNATURE-----

--VGbVC48uCTm2ibs5GAuejCrgwEgwEeoR4--