> In this case I would suggest to use class A<T <: T1> which leaves room open > to define lower bounds later on
IMHO that is bordering on unreadable - all those brackets are really confusing and hard on the eyes. Either way, using : does not prevent us from adding lower bounds later on - but even then, upper bound is the 99% use case, so I don't think it makes sense to design the syntax around a possible future upper bound. If we do support it in the future, I don't think anyone's going to care what it looks like, as it's unlikely most people will ever encounter it or need it. On Tue, Apr 26, 2016 at 10:15 PM, Robert Stoll <p...@tutteli.ch> wrote: > > >> -----Ursprüngliche Nachricht----- >> Von: Rasmus Schultz [mailto:ras...@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 <joshdifa...@gmail.com> >> wrote: >> > On Wed, Apr 20, 2016 at 8: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 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 >> > <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. >> >> >> >> ---------------- >> >> >> >> 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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
