Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92830
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.196 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: Wed, 27 Apr 2016 15:11:46 +1000
Message-ID: <CAF1yvARicPcNSFjvWxLB7u3AaJu6ySgb7cT9ykupDv72CiZf9g@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=001a114f7dbe4387b70531707241
Subject: Re: [PHP-DEV] [RFC:generics]
From: me@jesseschalken.com (Jesse Schalken)

--001a114f7dbe4387b70531707241
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.
>


I didn't understand the point of lower bound until I read this:
http://hhvm.com/blog/9215/covariance-contravariance-and-super-type-constrai=
nts

For example, this is a correctly typed array_merge() (ignoring the fact
that it's variadic, for simplicity):

function array_merge<T>(array<T> $a, array<T> $b):array<T> { ... }


(Keeping in mind that array<T> is covariant in T, so I can do
array_merge([new A()], [new B()]) and get an array<C>, provided A and B are
compatible with C.)

But if you have a class which has similar functionality, you would have to
type it as:

class Foo<T> {

    public function merge<V super T>(Foo<V> $o):Foo<V> { ... }

}


because the type of the result doesn't have to be Foo<T>, it can be Foo of
anything (V), as long as T of the current class is compatible with it (V
super T).



> 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 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
>

--001a114f7dbe4387b70531707241--