Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92567
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFKaYMo5rtXeV+uE85yuQ_xOpREiKF-zVdQN6T-vDET8WhFvzg@mail.gmail.com>
References: <CADqTB_gUbfu91QRm1U0KyDjai8DKw7yCE6QxgUecy60oq3Zi8Q@mail.gmail.com>
	<CAKiSzdCO83XM0zqAeFnjQEMJvbd0yBmYAFnj0H6AtDumofVbkw@mail.gmail.com>
	<CAKiSzdCCEF=7OWtvZETG3bRoByCCLqEAEjuLW_H6m7MmDtJ8_g@mail.gmail.com>
	<CAFKaYMoQUUFLqgDjOHj3W0+a63u3s=vqnU5gWMCj0zvmvXFF5Q@mail.gmail.com>
	<3cc8a4c7-2640-11ae-a67b-06f909ac1e27@texthtml.net>
	<CAESVnVqCZnrbHa+5_tSYG70VyvGfpZoDM98bEst3pg36HahYEg@mail.gmail.com>
	<57173859.4080501@rochette.cc>
	<CAFKaYMq_KFrygXwcuTd85y11X0_YMFop2tum+8jjXnkGKON6QA@mail.gmail.com>
	<CAFp73Xu2dM+E9Ri8dN-yt9Ha6-1UmOtD0RYq+HZXbjvzcWqJwg@mail.gmail.com>
	<CAFKaYMpWN+9uBqJ_p6-p14ZqYm0cm+q3LHkY3o9q7EvFCBS9Bg@mail.gmail.com>
	<CAFKaYMo5rtXeV+uE85yuQ_xOpREiKF-zVdQN6T-vDET8WhFvzg@mail.gmail.com>
Date: Wed, 20 Apr 2016 13:44:36 -0600
Message-ID: <CAObuZdtzOktA_k+Oq_rKheKJeBqzeJr7E29zjabRjH7MtEGp2A@mail.gmail.com>
To: Dominic Grostate <codekestrel@googlemail.com>
Cc: Guilherme Blanco <guilhermeblanco@gmail.com>, Mathieu Rochette <mathieu@texthtml.net>, 
	Josh Di Fabio <joshdifabio@gmail.com>, "Ben Scholzen 'DASPRiD'" <mail@dasprids.de>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>, Rasmus Schultz <rasmus@mindplay.dk>, 
	Mathieu Rochette <mathieu@rochette.cc>
Content-Type: multipart/alternative; boundary=001a1135bf38dae66f0530efd286
Subject: Re: [PHP-DEV] [RFC:generics]
From: derokorian@gmail.com (Ryan Pallas)

--001a1135bf38dae66f0530efd286
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 1: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 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.
>

--001a1135bf38dae66f0530efd286--