> -----Ursprüngliche Nachricht-----
> Von: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Gesendet: Montag, 13. Juli 2015 02:12
> An: Larry Garfield; internals@lists.php.net
> Betreff: Re: [PHP-DEV] PHP7 and types
>
> 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 = new Foo();
> > $f->bar = 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.
>
> 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
> 8 $f = new Foo();
> 9 $f->bar = 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
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 = 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
