AW: [PHP-DEV] [RFC:generics]

> -----Ursprüngliche Nachricht----- > Von: Rasmus Schultz [mailto:rasmus@mindplay.dk] > Gesendet: Montag, 25. April 2016 18:09 > An: Josh Di Fabio > Cc: Dominic Grostate; Guilherme Blanco; Mathieu Rochette; Ben Scholzen 'DASPRiD'; > Sara Golemon; PHP internals; Mathieu > Rochette > Betreff: Re: [PHP-DEV] [RFC:generics] > > > I really don't like 'as' in this context, even if Hack uses it, as it > > doesn't reflect in English terms what the code is doing. As others > > have already said, it reads as if 'T' is being aliased to 'Bar'. > > I second that. > > I hear the concerns about adding another reserved word "is" though, so I'd like > to suggest simply using a ":" ... as in: > > class A<T : T1> { ... } In this case I would suggest to use class A<T <: T1> which leaves room open to define lower bounds later on (either with <: as well or with :> as in scala) > > Consistent with return type-hints, it should feel like home? > > For sure nobody wants to type out "instanceof", and (as pointed out in the RFC) the > instanceof operator checks the type of > an object, which is *not* what this is doing - a type argument is not an "instance > of" anything. The ":" is more neutral in that > regard maybe? > > > On Thu, Apr 21, 2016 at 10:32 AM, Josh Di Fabio <joshdifabio@gmail.com> wrote: > > On Wed, Apr 20, 2016 at 8:17 PM, 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. > >> > > > > I really don't like 'as' in this context, even if Hack uses it, as it > > doesn't reflect in English terms what the code is doing. As others > > have already said, it reads as if 'T' is being aliased to 'Bar'. > > > > On Wed, Apr 20, 2016 at 8:17 PM, 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. > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: > http://www.php.net/unsub.php