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
> >
> >
>

Reply via email to