Re: [PSR-5] Intersection Types

2018-11-09 Thread Matthew Brown
I agree - I don’t think we want to encourage types that expand into monstrosities once the brackets have been evaluated out. Better to disallow (...) & C. > On Nov 9, 2018, at 1:15 PM, Chuck Burgess wrote: > > Ah, I had assumed they were same precedence in PHP... it's obviously been way > too

Re: [PSR-5][PSR-19] Is there a way to annotate interface that acts as iterator over some type?

2018-11-09 Thread Alan Gabriel Bem
How about allowing something like /** * @var Item[] */ interface Stream extends Traversable {} because I am sure this /** * @iterable Item */ interface Stream extends Traversable {} won't cut it as it is to much of an edge case to be pulled into standard. @Chuck I will outline your feature

Re: [PSR-5][PSR-19] Is there a way to annotate interface that acts as iterator over some type?

2018-11-09 Thread Chuck Burgess
I don't immediately see a way to accomplish this with tags. The closest thing to an idea I can come up with here will be dictating a rule to IDEs: for any variable representing a collection used by a foreach, the IDE must do deep class hierarchy mining to find *any and all potential return mechan

Re: [PSR-5] Intersection Types

2018-11-09 Thread Chuck Burgess
Ah, I had assumed they were same precedence in PHP... it's obviously been way too long since I've seen them in code. I agree with following PHP here, then, as Larry described... @return A & C | B & C CRB *about.me/ashnazg * On Fri, Nov 9, 2018 at 12:10 PM Larry Garfie

Re: [PSR-5] Intersection Types

2018-11-09 Thread Larry Garfield
Honestly, I'm skeptical that we want to develop a grammar for full algebraic type definitions in docs when the language doesn't support it. That risks encouraging some very bad practices, and if PHP itself ever adds native algebraic types it could get weird if there's any inconsistency (which t

Re: [PSR-5][PSR-19] Is there a way to annotate interface that acts as iterator over some type?

2018-11-09 Thread Larry Garfield
"This variable/return is an iterable of Foo objects" seems like an entirely reasonable thing to do. We already have the de facto standard of Foo[] to mean "an array of Foo objects", but that doesn't technically cover any iterable. (I'm really big on iterables these days, as anyone who follows

Re: [PSR-5] Nullable type shorthand in PHPDoc (e.g. `@return ?string`)

2018-11-09 Thread Chuck Burgess
I think I would argue that this example is not quite the same thing as a Nullable Type. I see the Nullable Type as a special case involving nulls, but not as *every* case involving nulls. I see it as a method signature type hint equivalent of `AnyClass|null`, so that the *signature* can still pro

[PSR-17] ResponseFactoryInterface

2018-11-09 Thread Rasmus Schultz
I know it's too late to bring up something like this, but... you don't notice until you actually start using it in real code. I wrote this class that uses PSR-17 to marshall between ResponseInterface and JSON-serializable data: https://gist.github.com/mindplay-dk/5fc5daa1cf5efd7d7ea2be99b1ec99b