On Wed, Apr 20, 2016 at 1:17 PM, Dominic Grostate <
codekest...@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.
>
I like instanceof the most, as I feel its more obvious. "is" is good IMO
from a user perspective, tho its a new keyword, its pretty obvious what's
happening (my T IS something, and will not be anything else). "as" makes me
feel like its going to either type-cast or T is going to be aliased as Bar
for later use in the class definition.
> ----------------
>
> 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.
>
Agreed, I think this should be left until after both RFCs have been decided
on.
>
> ----------------
>
> 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 makes sense to me to leave it separate. Lets get generic classes first.
>
> ----------------
>
> 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.
>
I think the RFC looks pretty great. I think you guys have put in a lot of
very good work speccing it out, thanks for that. As generics are the
biggest thing I feel missing that I use elsewhere, I really hope this
change gets accepted and fully working implementation!
>
> 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.
>
