Re: [PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
On Sat, Jun 15, 2019 at 9:02 AM Sebastian Bergmann wrote: > Am 13.06.2019 um 18:48 schrieb Nikita Popov: > > An update on this: The last part of covariance support has landed [1] a > few > > days ago and is part of 7.4 alpha 1. As already described, full variance > is > > only supported in conjunction with autoloading. When working in a single > > file or with explicit includes, the requirement that classes need to be > > declared before being referenced (including reference in variant type > > declarations) remains. > > Does "only supported in conjunction with autoloading" mean that covariance > is not (completely) supported when preloading is used? > Preloading is indeed currently limited to DAG class references (this includes class references in inheritance, in types and in constant expressions). Of course, it will fall back transparently to autoloading for the cases it cannot handle. If you run into this in practice (due to covariance or other reasons), feel free to report a bug -- there's some low hanging fruit in terms of restrictions we can remove. Nikita
Re: [PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
Am 13.06.2019 um 18:48 schrieb Nikita Popov: An update on this: The last part of covariance support has landed [1] a few days ago and is part of 7.4 alpha 1. As already described, full variance is only supported in conjunction with autoloading. When working in a single file or with explicit includes, the requirement that classes need to be declared before being referenced (including reference in variant type declarations) remains. Does "only supported in conjunction with autoloading" mean that covariance is not (completely) supported when preloading is used? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
On Wed, May 8, 2019 at 6:51 PM Levi Morrison wrote:
> On Wed, May 8, 2019 at 2:06 AM Nikita Popov wrote:
> >
> > On Tue, Jan 22, 2019 at 6:59 PM Levi Morrison wrote:
> >>
> >> On Tue, Jan 15, 2019 at 1:27 PM Christoph M. Becker
> wrote:
> >> >
> >> > On 04.01.2019 at 20:17, Levi Morrison wrote:
> >> >
> >> > > I intend to close the vote in a day or two, unless I hear of new>
> issues from Dmitry or others.
> >> > Any news here?
> >> >
> >> > --
> >> > Christoph M. Becker
> >>
> >> I sent this a week ago to Christoph only; oops.
> >>
> >> I have not heard any news. The vote is now closed. The RFC passes 39
> >> in favor to 1 against.
> >>
> >> Special thanks to Nikita and Dmitry who have helped find issues and
> >> review the patch. It will not be merged until the implementation
> >> quality is satisfactory.
> >
> >
> > As we're moving steadily towards 7.4 feature freeze, I'd like to discuss
> what we want to do with this RFC... The current implementation doesn't work
> correctly (I've done some more work in
> https://github.com/nikic/php-src/commits/variance-7.4, but it's also
> incomplete) and I have some doubts about how we're approaching this in
> general.
> >
> > This RFC really has two parts:
> > 1. The actual variance change. This is a very straightforward change and
> there are no issues here.
> > 2. The ability to check variance across multiple consecutive class
> definitions. This allows type declarations to reference classes that are
> declared later in the same file (but within one "block" of declarations).
> >
> > The second part is technically more dicey and somewhat arbitrary when
> seen in the wider scope of how class hoisting and early binding work in
> PHP: While PHP supports declaring classes "out of order" in some very
> simple cases like this...
> >
> > class B extends A {}
> > class A {}
> >
> > ...it will not work for anything more involved than that, for example
> >
> > class C extends B {}
> > class B extends A {}
> > class A {}
> >
> > will already generate a "class not found" error.
> >
> > Now the variance RFC tackles one very specific part of this
> long-standing issue: The types referenced in parameter and return types may
> be declared later in the file (even if used variantly), but all other uses
> of the types still need to respect the declaration order.
> >
> > I think that we should be separating these two issues (variance and
> declaration order), and land the simple variance support in 7.4, while
> tackling the declaration order problem *in full* separately (in PHP 8,
> because I think we may want to make some BC breaking changes, in particular
> by making the class hoisting unconditional.)
> >
> > Thoughts on this approach?
> >
> > Nikita
>
> I fully support this approach. I will prepare a patch for simple
> variance in PHP 7.4. I intend to leave the existing test cases that
> will fail without supporting consecutive declarations, but marked as
> expected failures.
>
> I think in PHP 8 we can already benefit from the [always generate
> fatal error for incompatible method signatures RFC][1]. We might also
> be able to make some improvements with compile-time errors on invalid
> "parent::" usage (previously done for PHP 7.4 but [backed out][2]),
> which might make things a bit more straightforward (it might not --
> turns out parent is not exactly what I thought it was).
>
> [1]: https://wiki.php.net/rfc/lsp_errors
> [2]:
> https://github.com/php/php-src/commit/deb44d405eb27a6654ad9a57c1e5f641218b22a4
An update on this: The last part of covariance support has landed [1] a few
days ago and is part of 7.4 alpha 1. As already described, full variance is
only supported in conjunction with autoloading. When working in a single
file or with explicit includes, the requirement that classes need to be
declared before being referenced (including reference in variant type
declarations) remains.
This feature turned out to be a *lot* harder than anticipated. My initial
assumption that this would mostly "just work" if we ignore the single file
case was very wrong...
Nikita
[1]
https://github.com/php/php-src/commit/8f8fcbbd397370b407dc2552c4bd6ee4ccb0e93b
Re: [PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
On Wed, May 8, 2019 at 2:06 AM Nikita Popov wrote:
>
> On Tue, Jan 22, 2019 at 6:59 PM Levi Morrison wrote:
>>
>> On Tue, Jan 15, 2019 at 1:27 PM Christoph M. Becker
>> wrote:
>> >
>> > On 04.01.2019 at 20:17, Levi Morrison wrote:
>> >
>> > > I intend to close the vote in a day or two, unless I hear of new> issues
>> > > from Dmitry or others.
>> > Any news here?
>> >
>> > --
>> > Christoph M. Becker
>>
>> I sent this a week ago to Christoph only; oops.
>>
>> I have not heard any news. The vote is now closed. The RFC passes 39
>> in favor to 1 against.
>>
>> Special thanks to Nikita and Dmitry who have helped find issues and
>> review the patch. It will not be merged until the implementation
>> quality is satisfactory.
>
>
> As we're moving steadily towards 7.4 feature freeze, I'd like to discuss what
> we want to do with this RFC... The current implementation doesn't work
> correctly (I've done some more work in
> https://github.com/nikic/php-src/commits/variance-7.4, but it's also
> incomplete) and I have some doubts about how we're approaching this in
> general.
>
> This RFC really has two parts:
> 1. The actual variance change. This is a very straightforward change and
> there are no issues here.
> 2. The ability to check variance across multiple consecutive class
> definitions. This allows type declarations to reference classes that are
> declared later in the same file (but within one "block" of declarations).
>
> The second part is technically more dicey and somewhat arbitrary when seen in
> the wider scope of how class hoisting and early binding work in PHP: While
> PHP supports declaring classes "out of order" in some very simple cases like
> this...
>
> class B extends A {}
> class A {}
>
> ...it will not work for anything more involved than that, for example
>
> class C extends B {}
> class B extends A {}
> class A {}
>
> will already generate a "class not found" error.
>
> Now the variance RFC tackles one very specific part of this long-standing
> issue: The types referenced in parameter and return types may be declared
> later in the file (even if used variantly), but all other uses of the types
> still need to respect the declaration order.
>
> I think that we should be separating these two issues (variance and
> declaration order), and land the simple variance support in 7.4, while
> tackling the declaration order problem *in full* separately (in PHP 8,
> because I think we may want to make some BC breaking changes, in particular
> by making the class hoisting unconditional.)
>
> Thoughts on this approach?
>
> Nikita
I fully support this approach. I will prepare a patch for simple
variance in PHP 7.4. I intend to leave the existing test cases that
will fail without supporting consecutive declarations, but marked as
expected failures.
I think in PHP 8 we can already benefit from the [always generate
fatal error for incompatible method signatures RFC][1]. We might also
be able to make some improvements with compile-time errors on invalid
"parent::" usage (previously done for PHP 7.4 but [backed out][2]),
which might make things a bit more straightforward (it might not --
turns out parent is not exactly what I thought it was).
[1]: https://wiki.php.net/rfc/lsp_errors
[2]:
https://github.com/php/php-src/commit/deb44d405eb27a6654ad9a57c1e5f641218b22a4
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
On Wed, May 8, 2019 at 4:06 AM Nikita Popov wrote:
> On Tue, Jan 22, 2019 at 6:59 PM Levi Morrison wrote:
>
> > On Tue, Jan 15, 2019 at 1:27 PM Christoph M. Becker
> > wrote:
> > >
> > > On 04.01.2019 at 20:17, Levi Morrison wrote:
> > >
> > > > I intend to close the vote in a day or two, unless I hear of new>
> > issues from Dmitry or others.
> > > Any news here?
> > >
> > > --
> > > Christoph M. Becker
> >
> > I sent this a week ago to Christoph only; oops.
> >
> > I have not heard any news. The vote is now closed. The RFC passes 39
> > in favor to 1 against.
> >
> > Special thanks to Nikita and Dmitry who have helped find issues and
> > review the patch. It will not be merged until the implementation
> > quality is satisfactory.
> >
>
> As we're moving steadily towards 7.4 feature freeze, I'd like to discuss
> what we want to do with this RFC... The current implementation doesn't work
> correctly (I've done some more work in
> https://github.com/nikic/php-src/commits/variance-7.4, but it's also
> incomplete) and I have some doubts about how we're approaching this in
> general.
>
> This RFC really has two parts:
> 1. The actual variance change. This is a very straightforward change and
> there are no issues here.
> 2. The ability to check variance across multiple consecutive class
> definitions. This allows type declarations to reference classes that are
> declared later in the same file (but within one "block" of declarations).
>
> The second part is technically more dicey and somewhat arbitrary when seen
> in the wider scope of how class hoisting and early binding work in PHP:
> While PHP supports declaring classes "out of order" in some very simple
> cases like this...
>
> class B extends A {}
> class A {}
>
> ...it will not work for anything more involved than that, for example
>
> class C extends B {}
> class B extends A {}
> class A {}
>
> will already generate a "class not found" error.
>
> Now the variance RFC tackles one very specific part of this long-standing
> issue: The types referenced in parameter and return types may be declared
> later in the file (even if used variantly), but all other uses of the types
> still need to respect the declaration order.
>
> I think that we should be separating these two issues (variance and
> declaration order), and land the simple variance support in 7.4, while
> tackling the declaration order problem *in full* separately (in PHP 8,
> because I think we may want to make some BC breaking changes, in particular
> by making the class hoisting unconditional.)
>
> Thoughts on this approach?
>
As I read it, the RFC [1] aims to address the variance problem. The
declaration problem is related - but separate. Seems to me, solving the
variance problem is the primary concern. Since declarations are therefore a
secondary concern, I agree with the separation. (More the so because, IMO,
it's better to solve a problem holistically.)
[1]: https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
Re: [PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
On Tue, Jan 22, 2019 at 6:59 PM Levi Morrison wrote:
> On Tue, Jan 15, 2019 at 1:27 PM Christoph M. Becker
> wrote:
> >
> > On 04.01.2019 at 20:17, Levi Morrison wrote:
> >
> > > I intend to close the vote in a day or two, unless I hear of new>
> issues from Dmitry or others.
> > Any news here?
> >
> > --
> > Christoph M. Becker
>
> I sent this a week ago to Christoph only; oops.
>
> I have not heard any news. The vote is now closed. The RFC passes 39
> in favor to 1 against.
>
> Special thanks to Nikita and Dmitry who have helped find issues and
> review the patch. It will not be merged until the implementation
> quality is satisfactory.
>
As we're moving steadily towards 7.4 feature freeze, I'd like to discuss
what we want to do with this RFC... The current implementation doesn't work
correctly (I've done some more work in
https://github.com/nikic/php-src/commits/variance-7.4, but it's also
incomplete) and I have some doubts about how we're approaching this in
general.
This RFC really has two parts:
1. The actual variance change. This is a very straightforward change and
there are no issues here.
2. The ability to check variance across multiple consecutive class
definitions. This allows type declarations to reference classes that are
declared later in the same file (but within one "block" of declarations).
The second part is technically more dicey and somewhat arbitrary when seen
in the wider scope of how class hoisting and early binding work in PHP:
While PHP supports declaring classes "out of order" in some very simple
cases like this...
class B extends A {}
class A {}
...it will not work for anything more involved than that, for example
class C extends B {}
class B extends A {}
class A {}
will already generate a "class not found" error.
Now the variance RFC tackles one very specific part of this long-standing
issue: The types referenced in parameter and return types may be declared
later in the file (even if used variantly), but all other uses of the types
still need to respect the declaration order.
I think that we should be separating these two issues (variance and
declaration order), and land the simple variance support in 7.4, while
tackling the declaration order problem *in full* separately (in PHP 8,
because I think we may want to make some BC breaking changes, in particular
by making the class hoisting unconditional.)
Thoughts on this approach?
Nikita
[PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
On Tue, Jan 15, 2019 at 1:27 PM Christoph M. Becker wrote: > > On 04.01.2019 at 20:17, Levi Morrison wrote: > > > I intend to close the vote in a day or two, unless I hear of new> issues > > from Dmitry or others. > Any news here? > > -- > Christoph M. Becker I sent this a week ago to Christoph only; oops. I have not heard any news. The vote is now closed. The RFC passes 39 in favor to 1 against. Special thanks to Nikita and Dmitry who have helped find issues and review the patch. It will not be merged until the implementation quality is satisfactory. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
On 04.01.2019 at 20:17, Levi Morrison wrote: > I intend to close the vote in a day or two, unless I hear of new> issues from > Dmitry or others. Any news here? -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
On Thu, Jan 3, 2019 at 8:28 AM Levi Morrison wrote:
>
> On Wed, Dec 19, 2018 at 4:10 PM Levi Morrison wrote:
> >
> > Thank you for the feedback and discussion on the [Covariant Returns
> > and Contravariant Parameters RFC][1].
> >
> > I have opened [voting on this RFC][2]. Given that this is a common
> > time for holidays for many people around the world it will be open
> > until at least January 2nd. Happy holidays!
> >
> > [1]:
> > https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
> > [2]:
> > https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#voting
>
> Currently there are 31 yes votes, and only 1 no vote. I will leave the
> vote open for a few more days while I examine an issue that Dmitry
> mentioned here on the list. When we have code like the following, no
> errors or warnings are generated but there should be a warning:
>
> class A {}
> class X {
> function m(A $z) {}
> }
> class Y extends X {
> function m(NotAnA $z) {}
> }
> ?>
>
> I am intentionally not generating a warning at runtime for some cases.
> The engine already issues a warning at compile time for some similar
> cases and I didn't want to duplicate the warning at runtime.
> Apparently this code is not precise enough.
I have a new pull request:
https://github.com/php/php-src/pull/3732
This fixes all currently known issues with the implementation,
including the snippet from my last message. There are a few todo items
left that may have issues, but so far we haven't hit those cases in
any code.
I intend to close the vote in a day or two, unless I hear of new
issues from Dmitry or others.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
On Wed, Dec 19, 2018 at 4:10 PM Levi Morrison wrote: > > Thank you for the feedback and discussion on the [Covariant Returns > and Contravariant Parameters RFC][1]. > > I have opened [voting on this RFC][2]. Given that this is a common > time for holidays for many people around the world it will be open > until at least January 2nd. Happy holidays! > > [1]: https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters > [2]: > https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters#voting Currently there are 31 yes votes, and only 1 no vote. I will leave the vote open for a few more days while I examine an issue that Dmitry mentioned here on the list. When we have code like the following, no errors or warnings are generated but there should be a warning: I am intentionally not generating a warning at runtime for some cases. The engine already issues a warning at compile time for some similar cases and I didn't want to duplicate the warning at runtime. Apparently this code is not precise enough. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
