Re: [RFC:generics]

"instanceof" implies to me that the right hand side is a class/interface name, since that's what's expected with the "instanceof" operator, rather than a type. If I can do "Foo<T instanceof array<Bar>>" I would expect to be able to do "if ($t instanceof array<Bar>) ...", but I can't. I think unless the "instanceof" operator is updated to be able to do checks with arbitrary type expressions, a different keyword should be used for generic type constraints so as not to imply any misleading correspondence with the "instanceof" operator. So I would prefer "as". It's also shorter, and matches Hack. On Thu, Apr 21, 2016 at 5:17 AM, Dominic Grostate < codekestrel@googlemail.com> 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. > > ---------------- > > 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. >