> -----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
