On Sun, Jul 12, 2015 at 4:51 PM, Alan Willms <alanwil...@gmail.com> wrote:
> 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 <la...@garfieldtech.com>: > > > On 07/12/2015 11:16 AM, Marcio Almada wrote: > > > >> Stas, > >> > >> 2015-07-12 5:10 GMT-03:00 Stanislav Malyshev <smalys...@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> > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
