On Wed, Apr 20, 2016 at 12:17 PM, Dominic Grostate
<codekest...@googlemail.com> wrote:
> 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'm against adding a new keyword anywhere we can trivially avoid it,
and this is one of those places where avoidance is trivial.
Preference for 'as', since it conform's to HackLang's generics (and
it's fewer keystrokes), but 'instanceof' has enough clarity to it that
I wouldn't complain.> 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. > IMO. This feature is complex enough without unions/intersections, and they have the concurrency problem with the fact that the Union Types RFC is also under discussion. I think if both that RFC and this one (without complex limits) both pass, then it makes sense to do a followup RFC to combine them in logical ways. > 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. > Callable is probably a bad use-case for this extension of generics, but I'd like to see array<Tk,Tv> at some later point. That said, both should be considered out of scope of this RFC in my opionion. > 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. > I don't think Reflection necessarily needs to be part of the RFC, but if we can come up with something which makes sense it doesn't have to be out of scope. Really, the in/ex-clusion of this part will come down to whether or not someone comes up with a sane API for it. > 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. > +1 from me. This is an essential piece of being able to do comprehensive static analysis of PHP programs, and static analysis has already saved my butt more times than I care to count. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
