> 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> { ... }
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
