Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92851
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.214.195 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAFp73XuLSr2=ENJ_VaaNAU+K_bYDLcF32cj3JBb7N2-jzUkMNw@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>
	<CAKiSzdARnKM9=KwRhXJ1-2v44ueMAtBge+EywzDOT3+qkJ9xJg@mail.gmail.com>
	<CADqTB_jrfEBAesWTjDjzqTw5GnNQskgRfd_y8tOUyPF-e46ujA@mail.gmail.com>
	<013101d19ff8$596b6010$0c422030$@tutteli.ch>
	<CAFp73XuLSr2=ENJ_VaaNAU+K_bYDLcF32cj3JBb7N2-jzUkMNw@mail.gmail.com>
Date: Wed, 27 Apr 2016 23:08:02 +0200
Message-ID: <CADqTB_gKn_AvJWiyWWFqcYLwMTaw7mHYdT=rGwsaBGMjDYLxNA@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: Robert Stoll <php@tutteli.ch>, Josh Di Fabio <joshdifabio@gmail.com>, 
	Dominic Grostate <codekestrel@googlemail.com>, Mathieu Rochette <mathieu@texthtml.net>, 
	"Ben Scholzen 'DASPRiD'" <mail@dasprids.de>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>, Mathieu Rochette <mathieu@rochette.cc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC:generics]
From: rasmus@mindplay.dk (Rasmus Schultz)

Thanks Guilherme - this pretty much sums up how I feel about features 2-5.

Plain generics with upper bounds, I find some case where it's missing,
almost daily.

As for the gist you posted, I'm lost, what does this have to do with reflec=
tion?


On Tue, Apr 26, 2016 at 10:50 PM, guilhermeblanco@gmail.com
<guilhermeblanco@gmail.com> wrote:
> Hi all,
>
> Yesterday I spent a considerable 2h talking about Generics in Doctrine
> channel.
> We discussed the specifics of each boundary that PHP's implementation cou=
ld
> take advantage. Here are our findings, which I'll illustrate using Java
> equivalents:
>
> 1- Upper bounds (T extends A)
>
> We all understood they're required. Whenever you mention class Foo<T is A=
>
> {}, we're talking that T can be A or any of its subtypes.
> Also, we debated over intersection types. It's an edge case, and its supp=
ort
> could be done as a subsequent RFC once union and intersection types gets
> resolved.
>
> 2- Lower bounds (T super A)
>
> It was just not possible to come up with a single use case or possibility=
.
> It not only violates Liskov, but it also doesn't make any sense in the
> context of PHP.
> When we debate about Java, it does make sense because of polymorphism and
> the requirement removal of implementing multiple methods.
>
> 3- Unbounded wildcards (?)
>
> It wouldn't be necessary in the context of PHP. Why?
> Once we introduce Generics, the difference between process(List $list) an=
d
> process(List<?> $list) would be none, as due to PHP's nature.
>
> 4- Upper bounded wildcard (? extends A)
>
> Again, invalid in the context of PHP. Let me explain why...
> In Java context, whenever you declare something as List<A>, you can only =
add
> As to the list, but no subtypes. When you declare List<? extends A>, you =
can
> add A and also any of its subtypes.
> PHP is loose in this restriction, so there's no way of strict-ing to only=
 A
> but not subtypes. Defining as List<A> would be enough, and PHP wouldn't
> support adding A and A only.
>
> 5- Lower bounded wildcard (? super A)
>
> Applies the same concept of #2. PHP doesn't need it as it doesn't fully
> support polymorphism.
>
> 6- Reflection
>
> We discussed over an example I extracted from a piece of code I currently
> work on. We came with several ideas, but couldn't wrap up (but we're 80%)=
 a
> valid approach. The example we debated was this one:
> https://gist.github.com/guilhermeblanco/56ec0e11e7b029c2cfdcaf6fe2323742
>
>
>
>
> So I'll have to say sorry for poking around of "missing implementation"
> while in reality most of them cannot be applied in the context of PHP.
> I've reviewed the RFC again and it mostly makes sense surrounding
> boundaries. I still have to talk about diamond operator and constructor
> generic type.
>
>
> []s,
>
>
> On Tue, Apr 26, 2016 at 4:15 PM, Robert Stoll <php@tutteli.ch> wrote:
>>
>>
>>
>> > -----Urspr=C3=BCngliche 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 i=
t
>> > > 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 i=
t
>> > > 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.  Likewi=
se
>> > >> if this feature becomes approved in generics, it would make sense t=
o
>> > >> 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 featur=
e
>> > >> 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 informatio=
n
>> > >> about a class in a backwards compatible manner.  So we will need so=
me
>> > >> 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 i=
t
>> > >> 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
>>
>>
>
>
>
> --
> Guilherme Blanco
> Lead Architect at E-Block