On 04/20/2016 09:17 PM, Dominic Grostate wrote:
> Thanks for you're input everyone.
>
> So far, we have read some ideas for handling upper bounds, or multiple
> there of.
> The preferred keywords appear to be either "as" or "instanceof".
>
> class Foo<T as Bar> {}
> class Foo<T instanceof Bar> {}
>
> We would like to know for sure then if everyone is largely against the
> addition of an "is" keyword, in favour of one of the other two.
I don't mind having a new keyword and is would be my first choice because
using one of the other two would feel odd. in T instanceof Bar I expect
T to be a
variable, not a type and with T as Bar I feel like I'm telling PHP "T is
not a Bar but
treat as if it is"
I'm not that well aware of the implication of adding a new keyword but I
thought
it would not be a big deal since
https://wiki.php.net/rfc/context_sensitive_lexer
has passed (I'm not saying it's not important, just that using the most
appropriate
keyword is very important too)> > ---------------- > > There is also a desire to include unions and intersections. > Presently though, this feature feels tied in with > https://wiki.php.net/rfc/union_types meaning if union types are approved, > then generics would have to support them as well. Likewise if this feature > becomes approved in generics, it would make sense to support them in > regular type hints as well. > > ---------------- > > The RFC makes a reference to generic closures, which may look something > like this: > > function my_function(callable<Foo, Bar> $func) { > > } > > However, an RFC already exists which is very similar to this feature at > https://wiki.php.net/rfc/callable-types > As it currently standards these RFCs appear incompatible with each other > (please correct me if I am wrong). > > My question about this is would you prefer the generics RFC exclude this > part in favour of a separate or later RFC. > Initially the proposal included generic arrays "array<string>". However to > ease the implementation it was decided that should be a separate feature. > So we'd like to find out if everyone else feels the same way about callable > types. > > ---------------- > > This RFC currently doesn't specify in detail how reflection would work. We > have attempted a few API designs, but due to generic classes being ... > generic, it is difficult to find a suitable way to glean information about > a class in a backwards compatible manner. So we will need some help on > this one. > > ----------------- > > Aside from these top issues on our own list, however does everyone feel > about the proposal in general? > As the RFC is still in draft, we will continue to make changes to it as > more popular idea pop up, so please continue. > > Thanks. > > PS: I wasn't properly subscribed to the mailing list, so I missed a few > important messages that were mailed directly to internals, but hopefully > I've managed to fix that now. > -- Mathieu Rochette
