Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101368
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.49 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAFMT4NrMRZRJm=sN+TpY-QJgri17tpFuxJzucTFx0QRWB_J3cg@mail.gmail.com>
References: <CAH0Uv3HrjXmbdw+XXK7ed7bFSSofxZeLirvooGfAzAHrV0xDkA@mail.gmail.com>
 <CAFMT4Nq=zaopsjWt=50Mj+iy8x_vR8f2YyzS4mz8uhsx6iCfBg@mail.gmail.com>
 <CAH0Uv3H4FGvJnSaibhBDZ1QGs3OW1agD81Yb-WFZz6fpJfG--w@mail.gmail.com> <CAFMT4NrMRZRJm=sN+TpY-QJgri17tpFuxJzucTFx0QRWB_J3cg@mail.gmail.com>
Date: Mon, 18 Dec 2017 22:21:53 +0100
Message-ID: <CAH0Uv3EVQdZ2wzXgXPDqtVun24fAT1FdkRwrr4B1VQfX-vSs-g@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Covariance, again
From: andreas@dqxtech.net (Andreas Hennings)

> I really think we ought to tackle covariant returns and contravariant parameters

My "algorithm" could be extended for contravariance:
Whenever a method has a parameter type hint that differs from the
parent type hint, autoload the class of the parent type hint.

I think I know too little about the internal workings of PHP to
understand why your examples would break.
I think we should give it a try, and write your examples as unit tests
to try to crash it.

If we indeed can produce circularity problems, then I might have more ideas.
I think the main idea in my algorithm about which classes needs to be
autoloaded and which don't is good.
Maybe at some point we need to write a class into the table of defined
classes, before it is fully verified.

At some point, for a different purpose, I thought about "stub"
classes, which have all the information from the declaration itself,
but not from any parent class. So we could write classes into the stub
table and then later write the completed thing into the actual class
table/list.
But maybe we don't need to go that far.

If I were to do this, it would be my first shot on the php engine
itself. Not going to happen today, but maybe I will find time for it
in a future month or so.
I am sure if/when I have done this, I can write more knowledgeable
posts here on this mailing list.
Of course if someone else wants to step up, go ahead.

I think the goal and spec is pretty clear. So once we have a
proof-of-concept implementation and show that it can be done and the
problems can be solved, it would be straightforward to make an RFC.
If we would do the RFC first, people would have to vote on something
which is unclear if it can be implemented.


On 18 December 2017 at 21:48, Levi Morrison <levim@php.net> wrote:
> On Mon, Dec 18, 2017 at 11:52 AM, Andreas Hennings <andreas@dqxtech.net> wrote:
>>> I believe your algorithm fails on this simple setup:
>>
>> Another comment I want to make here:
>> The examples you give each have multiple class declarations per file.
>> I would personally not care much, if these result in fatal error.
>> All of this code used to be illegal until now (because no covariance
>> support), so it would not be a BC problem if some of it continues to
>> be illegal.
>
> Just because it isn't a backwards compatibility break doesn't mean
> it's a good way forward. Right now people have covariant returns -
> they just don't express it in the signature because we don't allow it.
> Wouldn't it seem odd that if the bodies of the methods stayed the same
> and all they did was update the signature that it somehow breaks their
> code?
>
> I have some ideas about minimizing this impact but I really think we
> ought to tackle covariant returns and contravariant parameters at the
> same time. Any endeavor to add one should add the other to create a
> cohesive design that works in both cases.