Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92940
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.66 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFKaYMoZbou9V+a1JJdLJvOsWpKVhkGpm7F58srXgmmKmDmt1A@mail.gmail.com>
References: <CADqTB_gUbfu91QRm1U0KyDjai8DKw7yCE6QxgUecy60oq3Zi8Q@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>
	<CAF1yvAR+++W8TNhTWD4BMoRXnAMV7wPwqosx-Szvg5fOK5q6sg@mail.gmail.com>
	<CAFp73Xsr0sZTJmBZX4xXb7T4G-mLop+OF+ciDmcvv05JeVLyBQ@mail.gmail.com>
	<c624ebc1-802e-80b1-9eaf-5bb8d73205c3@gmail.com>
	<CAFKaYMoZbou9V+a1JJdLJvOsWpKVhkGpm7F58srXgmmKmDmt1A@mail.gmail.com>
Date: Fri, 29 Apr 2016 16:45:08 +0100
Message-ID: <CAFKaYMr-k1pxZDyczLwQtWTeBKA=LPT6XsZYzJ7i56kY5-_epw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114b26e610c5fe0531a18713
Subject: Re: [PHP-DEV] [RFC:generics]
From: codekestrel@googlemail.com (Dominic Grostate)

--001a114b26e610c5fe0531a18713
Content-Type: text/plain; charset=UTF-8

It's not insane, it's liskov substitution.  But that is an insane example,
typical of Java to create a type that extends it's parent by adding value
constraints.. directly violating the principle.
On 29 Apr 2016 4:22 p.m., "Rowan Collins" <rowan.collins@gmail.com> wrote:

guilhermeblanco@gmail.com wrote on 29/04/2016 15:26:

> 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).
>> >
>> >
>>
> Wrong. This is documented here
> https://docs.oracle.com/javase/tutorial/java/generics/upperBounded.html
> and
> specifically states:
>
> To write the method that works on lists of Number and the subtypes of
> Number,
>
>> >such as Integer, Double, and Float, you would specify List<? extends
>> >Number>. The term List<Number> is more restrictive than List<? extends
>> >Number> because the former matches a list of type Number only, whereas
>> >the latter matches a list of type Number or any of its subclasses.
>>
>

Forgive me for butting in if I'm completely wrong, but is the confusion
here between *declaring an instance* and *declaring a parameter constraint*?

I think the point is that you can declare variables as follows:

List<Integer> li;  // only accepts Integer
List<Double> ld; // only accepts Double
List<Number> ln; // accepts any Number, even if it is in fact an Integer or
Double instance

But if you then define a function accepting a parameter:

public static double sumOfList(List<Number> list)


Now your argument has to be of type List<Number>; you can pass "ln" above,
but not "li" or "ld". To relax the function's contract, you can write this
instead:

public static double sumOfList(List<? extends Number> list)

Now the argument can be a List<Integer> or List<Double>, so "li" and "ld"
are legal arguments.


The reason the default case is to be invariant, rather than covariant, is
explained on the blog post Jesse linked to:
http://hhvm.com/blog/9215/covariance-contravariance-and-super-type-constraints


In a nutshell, consider this function:

function addPiToList(List<Number> $list): void
{
$list->add(3.1415); // for the sake of example, assume 3.1415 instanceOf
Double
}

If we allow covariance, then we can run addPiToList(new List<Integer>) and
the type conditions are met; clearly this is not sane, and is going to
result in an error somewhere.

So we need to be stricter:

function addPiToList(List<Double> $list): void

But the actual contract we want here is "any list we can legally add a
Double to", and if we get a List<Number> or a List<*>, it would work fine,
so our check is too strict. What's needed is a way to declare our function
as contravariant:

function addPiToList(List<? super Double> $list): void

Now we can pass in a List<Double> or a List<Number>, but not a
List<Integer>, and our contract holds nicely.


It took me a while to get my head around, but I think the above makes
sense...


Regards,
-- 
Rowan Collins
[IMSoP]

--001a114b26e610c5fe0531a18713--