Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87130
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: "'Rasmus Lerdorf'" <rasmus@lerdorf.com>,
	"'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> <55A30267.10204@lerdorf.com>
In-Reply-To: <55A30267.10204@lerdorf.com>
Date: Mon, 13 Jul 2015 09:16:35 +0200
Message-ID: <006201d0bd3b$da87d700$8f978500$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQLKj5jnHzHAN4ZA333OTv//ogPhywCg8n0KAoyJZwQCR1aMUAM9yVxOAfizZMACH29I7QEk6o7fm3XaWkA=
Content-Language: de-ch
Subject: AW: [PHP-DEV] PHP7 and types
From: php@tutteli.ch ("Robert Stoll")



> -----Urspr=C3=BCngliche Nachricht-----
> Von: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
> Gesendet: Montag, 13. Juli 2015 02:12
> An: Larry Garfield; internals@lists.php.net
> Betreff: Re: [PHP-DEV] PHP7 and types
>=20
> 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
> > find bugs for you. Eg:
> >
> > class Foo {
> >   public Bar $bar;
> > }
> >
> > $f =3D new Foo();
> > $f->bar =3D new Baz(); // This line is clearly wrong and the =
compiler
> > can check it for you.
> >
> > That's what the benefit would be.  Easier IDE auto-completion is a
> > nice extra, but not the main goal.
> >
> > +1 from me in 7.1.
>=20
> 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:
>=20
> % cat -n test.php
>      1	<?php
>      2	class Baz { }
>      3	class Foo {
>      4		/** @var Bar $bar */
>      5		public $bar;
>      6	}
>      7
>      8	$f =3D new Foo();
>      9	$f->bar =3D new Baz();
>=20
> % ./phan test.php
> Files scanned: 1
> Time:		0.11s
> Classes:	2
> Methods:	0
> Functions:	0
> Closures:	0
> Traits:		0
> Conditionals:	0
> Issues found:	1
>=20
> test.php:9 TypeError property is declared to be bar but was assigned =
Baz
>=20
> 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.
>=20
> 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.
>=20
> -Rasmus

Another point of discussion should be how strict a property type hint =
will be. Currently, parameter type hints are only binding for the call =
side but not within the function body.
For instance, function foo(Foo $x){ $x =3D 1;} is perfectly valid. It =
certainly has little sense to have the same semantics for properties but =
then we introduce another inconsistency and should maybe fix the =
behaviour of parameter type hints first.