PHP7 and types

What about arrays? How do I declare Foo[] ?

http://ocramius.github.io/extremely-defensive-php/#/69

2015-07-12 16:37 GMT-03:00 Larry Garfield larry@garfieldtech.com:

Stas,

2015-07-12 5:10 GMT-03:00 Stanislav Malyshev smalyshev@gmail.com:

Hi!

Not completely bogus. At least with typed properties you won't need to

actually write the docblocks to have the IDE "hints". It's a minor win
for IDE users too.

I don't see "not needing to write docblocks" as a win, quite the
contrary.

Of course it's a win. Or do you like to write docblocks for every
single class property or method (even when the member is obvious) just
to have a "@var" so your IDE can work?

Not to mention you won't get any runtime/compile time check or
optimization from docblock tags, that's the main point of having typed
properties.

In fact, in a number of projects I worked with, code without

proper documentation (including docblocks) simply wasn't accepted into
the repository.

If you are using the term "proper documentation" to justify docblocks
everywhere even if they contain just a "/** @var string */", it's a
sign we've been using comments against us all this time (even if we
called it "doc comments").

But thankfully we are moving PHP to another direction. Do you remember
the "return types" voting results?
https://wiki.php.net/rfc/return_types#vote. That's because "function()
: type" is self documented and much more maintainable than than a
possibly sloppy "/** @return type */" on top of every method on a
codebase.

While I don't think this needs to be mandatory, I also don't see major

difference - so you have to write type instead of docblock, you still
have to write something.

But with the benefits already cited above. Docblocks should not be a
place for type information anymore, this was a workaround and we've
been slowly replacing it with a better solution (opt in types).
Property types seems to be the next logical step after adding return
types and scalar types.

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.

--Larry Garfield

Since there is not typed arrays in PHP I would say you declare it as an
array. Though in this case I would suggest a collection class that
implements iterator and countable and type hint for this collection and
make its job be to be a container of a specific type.

class WagonCollection implements Iterator, Countable {
private array $wagons = [];
private int $index = 0;

public function addWagon(Wagon $w) {
$this->wagons[] = $w;
}

// implementations for Iterator and Countable
}

However, I could see an argument being made for typed arrays, but that is
not the point of my suggested RFC and a separate RFC would need to be
created for that.

PS. Please bottom post instead of top posting. mailing list rules
<http://git.php.net/?p=php-src.git;a=blob_plain;f=README.MAILINGLIST_RULES;hb=HEAD

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

By the way, I forgot to add that you can't possibly say that this line
is clearly wrong without knowing what Baz is and you didn't define Baz.
So the only thing clearly wrong with that line is that the Baz class
doesn't exist which has nothing to do with the property type.

If you have:

class Bar { }
class Baz extends Bar { }

Then that line is perfectly valid since Baz is an instance of Bar which
would meet the type criteria provided. And this also shows that the
compiler can't actually check that necessarily. We don't know whether
Baz is an instance of Bar at compile-time.

-Rasmus

-----Ursprüngliche 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

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.

No, not "just" my IDE can work. IDE is just the side effect. Proper

documentation does much more than that.
It seems to go off topic. Docblocks are only slightly related to this
thread. The same could be said about annotation (which are widely used too).

Coming from a background of 'traditional' php design, all of my code and
the libraries I use are documented via phpdoc style annotation which the
IDE picks up, and phpdocumentor1 produced a good API description. This
was also a GOOD basis to tidy up the various changes through PHP5.x

Today much of the infrastructure to make that work is broken and
http://lsces.org.uk/wiki/bitweaver+documentation is a starting point at
getting the material all up to date. The original documentation had a
few errors on the log file, but http://lsces.org.uk/bwdocs2/index.html
is the version I've been working on and is listing 3300 errors in the
documentation! The next step is to work out how to address those errors,
but once again that is unproductive work so perhaps fixing the problems
with the older V1 documenter may be a better use of time? The rules
phpdocumenter2 follow seem far adrift from the original 'standard'. So
it WOULD be nice if there was an approved standard rather than these
seeming to be subject to different interpretation all the time.

This before addressing the problems of PHP7 migration ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk