Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92921
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
Sender: jesseschalken@gmail.com
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: Fri, 29 Apr 2016 18:55:32 +1000
Message-ID: <CAF1yvAR+++W8TNhTWD4BMoRXnAMV7wPwqosx-Szvg5fOK5q6sg@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: Robert Stoll <php@tutteli.ch>, Rasmus Schultz <rasmus@mindplay.dk>, 
	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: multipart/alternative; boundary=001a113ebd8033186405319bce9d
Subject: Re: [PHP-DEV] [RFC:generics]
From: me@jesseschalken.com (Jesse Schalken)

--001a113ebd8033186405319bce9d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 27, 2016 at 6:50 AM, 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
> support could be done as a subsequent RFC once union and intersection typ=
es
> 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.
>


You can add subtypes of A to a List<A> in Java. What List<? extends A>
means is that the list itself may be a list of any type, provided that type
is compatible with A. So if B extends A, List<B> is compatible with List<?
extends A>, and when reading items you can assume they will be compatible
with A (since B extends A) but you can't add an A (because it's actually a
list of Bs).

Similarly, List<? super A> means it may be a list of A or some super type
of A. So if A extends C, List<C> is compatible with List<? super A>, and
you can add an A (because A is compatible with C) but when reading items
you can't assume they're going to be As (because it's actually a list of
Cs).

This is my understanding of variance behaviour and notation in the three
languages I'm most familiar with:

Covariance (Foo<Sub> is a subtype of Foo<Super>)

Java  Foo<? extends T> at usage  Methods accepting T as parameter cannot be
called
Hack  Foo<+T> at declaration     Methods accepting T as parameter cannot be
defined
C#    Foo<out T> at declaration  Methods accepting T as parameter cannot be
defined


Contravariance (Foo<Super> is a subtype of Foo<Sub>)

Java  Foo<? super T> at usage   Methods returning T can be called but
return Object
Hack  Foo<-T> at declaration    Methods returning T cannot be defined
C#    Foo<in T> at declaration  Methods returning T cannot be defined


Invariance (no relationship between Foo<Super> and Foo<Sub>)

Java  Foo<T> at usage           Methods accepting T and returning T can
both be called
Hack  Foo<T> at declaration     Methods accepting T and returning T can bot=
h be
defined
C#    Foo<T> at declaration     Methods accepting T and returning T can bot=
h be
defined


(There are more general rules for method signatures when T is used as the
parameter for another generic type, but I can't remember what they are.)

I can't see variance mentioned in the RFC, but when I asked about it when
the RFC was posted on Reddit, Rasmus said the type parameters would always
be covariant, so Foo<A> in PHP as an annotation would be equivalent to
Foo<? extends A> in Java, even though this has the opposite of the intended
effect if Foo has methods which accept a parameter of the generic type,
such as something like List<T>::add(T $element), Callback<T>::run(T $data)
or Box<T>::setContents(T $contents).

My view is that PHP's generics should be invariant to start with (generic
arrays can still be covariant of course, since they are passed by value),
maintaining type safety and matching the behaviour of Java, Hack and C# for
type parameters without variance annotations, and variance syntax should be
added later as another RFC as demand arises.



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 Scholze=
n
> > '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, s=
o
> > 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 i=
n
> > 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.co=
m
> >
> > 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 =
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
> > > > <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.
> 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 featu=
re
> > > >> 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 exclud=
e
> > > >> 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 informati=
on
> > > >> 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
> >
> >
> >
>
>
> --
> Guilherme Blanco
> Lead Architect at E-Block
>

--001a113ebd8033186405319bce9d--