Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Michał Brzuchalski]

Hi everyone,

proposed PR https://github.com/php/php-src/pull/2080 was rebased before
variance patch and adjusted to current master implementation.
Currently waiting for merge.

Thanks everyone for voting.

regards,
--
Michał Brzuchalski

2017-06-03 12:54 GMT+02:00 Nikita Popov :

> On Wed, May 17, 2017 at 12:34 PM, Michał Brzuchalski <
> mic...@brzuchalski.com> wrote:
>
>> Hi everyone,
>>
>> I would like to put Object Type RFC up to a vote for inclusion in PHP 7.2.
>>
>> Previously there were some concerns about adding named types in the
>> future,
>> but we came to the conclusion that each of them can be solved if there are
>> proposals in the future.
>>
>> Voting starts today, 2017-05-17, and will close after two weeks on the
>> Wednesday 2017-05-31 at midnight.
>>
>> The RFC and voting widget can be found here: https://wiki.php.net/
>> rfc/object-typehint 
>>
>> The vote is a straight Yes/No vote for accepting the RFC and merging the
>> patch which require 2/3 majority.
>> The additional vote is also a straight Yes/No vote for accepting variance
>> behaviour on the object type which also require 2/3 majority.
>>
>
> I've closed the vote on https://wiki.php.net/rfc/object-typehint, as it
> was supposed to close three days ago.
>
> The RFC has been accepted with 32 in favor and 3 against. Variance support
> has been rejected with 10 in favor and 20 against.
>
> Please rebase your implementation and update it for the decision regarding
> the variance.
>
> Thanks,
> Nikita
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Nikita Popov]

On Wed, May 17, 2017 at 12:34 PM, Michał Brzuchalski  wrote:

> Hi everyone,
>
> I would like to put Object Type RFC up to a vote for inclusion in PHP 7.2.
>
> Previously there were some concerns about adding named types in the future,
> but we came to the conclusion that each of them can be solved if there are
> proposals in the future.
>
> Voting starts today, 2017-05-17, and will close after two weeks on the
> Wednesday 2017-05-31 at midnight.
>
> The RFC and voting widget can be found here: https://wiki.php.net/
> rfc/object-typehint 
>
> The vote is a straight Yes/No vote for accepting the RFC and merging the
> patch which require 2/3 majority.
> The additional vote is also a straight Yes/No vote for accepting variance
> behaviour on the object type which also require 2/3 majority.
>

I've closed the vote on https://wiki.php.net/rfc/object-typehint, as it was
supposed to close three days ago.

The RFC has been accepted with 32 in favor and 3 against. Variance support
has been rejected with 10 in favor and 20 against.

Please rebase your implementation and update it for the decision regarding
the variance.

Thanks,
Nikita

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Michał Brzuchalski]

2017-05-17 19:12 GMT+02:00 Dan Ackroyd :

> > We were thinking about enumerations
>
> Who do you mean 'we', kemosabe?
>

My apologies. I was a little hurry.


>
> > Especially when taking Java pattern
>
> Java has been limited in its design as almost everything had to be an
> object, whether or not it was a good fit for what was needed.
>
> For me, objects are good at storing state, hiding implementation
> details and allowing type substitution.pretty much none of those
> things apply to enums, and so make me think that forcing enums to be
> objects isn't always the right thing to do.
>
> cheers
> Dan
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Michał Brzuchalski]

2017-05-17 18:43 GMT+02:00 Levi Morrison :

> I'm not intending to derail the thread but let's consider your statement:
> your proposal constrains us to choosing something Java-like instead of
> having all options. Think closely about that: you are advocating that we
> constrain us to Java-like enums when there are many, many options and we
> get what for that trade-off? A simpler way to implement variance for the
> object-type only? No thanks.


No offence Levi, it was just an example of enums implementation.
Maybe I should not now point it in this thread.
My apologies.


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Dan Ackroyd]

> We were thinking about enumerations

Who do you mean 'we', kemosabe?

> Especially when taking Java pattern

Java has been limited in its design as almost everything had to be an
object, whether or not it was a good fit for what was needed.

For me, objects are good at storing state, hiding implementation
details and allowing type substitution.pretty much none of those
things apply to enums, and so make me think that forcing enums to be
objects isn't always the right thing to do.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Levi Morrison]

On Wed, May 17, 2017 at 10:26 AM, Michał Brzuchalski  wrote:

> Thank your Levi for your explanation.
>
> 2017-05-17 16:47 GMT+02:00 Levi Morrison :
>
>>
>>
>> On Wed, May 17, 2017 at 4:34 AM, Michał Brzuchalski <
>> mic...@brzuchalski.com> wrote:
>>
>>> Hi everyone,
>>>
>>> I would like to put Object Type RFC up to a vote for inclusion in PHP
>>> 7.2.
>>>
>>> Previously there were some concerns about adding named types in the
>>> future,
>>> but we came to the conclusion that each of them can be solved if there
>>> are
>>> proposals in the future.
>>>
>>> Voting starts today, 2017-05-17, and will close after two weeks on the
>>> Wednesday 2017-05-31 at midnight.
>>>
>>> The RFC and voting widget can be found here: https://wiki.php.net/
>>> rfc/object-typehint 
>>>
>>> The vote is a straight Yes/No vote for accepting the RFC and merging the
>>> patch which require 2/3 majority.
>>> The additional vote is also a straight Yes/No vote for accepting variance
>>> behaviour on the object type which also require 2/3 majority.
>>>
>>> Thanks!
>>> --
>>> regards / pozdrawiam,
>>> --
>>> Michał Brzuchalski
>>> about.me/brzuchal
>>> brzuchalski.com
>>>
>>
>> An emphatic "no" on variance for me. This is for two over-arching reasons:
>>
>>   1. Object variance should be implemented when we have generalized
>> variance for all types. By special casing it now we open ourselves to the
>> possibility that its implementation or semantics will differ from the
>> generalized solution.
>>
>>   2. The way it is implemented prevents us from adding new types which
>> are not objects. The reason is that the way this is implemented it just
>> assumes that an unknown type is an object type. If we add a feature such as
>> an enumerations (enums) this assumption probably breaks and cannot be fixed
>> while maintaining BC as it would almost certainly need to trigger an
>> autoload.
>>
>>
> We were thinking about enumerations and generally IMHO, they can be
> implemented as objects though. Especially when taking Java pattern
> http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html when dealing
> with enumeration means dealing with a special purpose and special kind of
> objects, which are IMO more powerful with methods which can implement some
> behaviour.
>

I'm not intending to derail the thread but let's consider your statement:
your proposal constrains us to choosing something Java-like instead of
having all options. Think closely about that: you are advocating that we
constrain us to Java-like enums when there are many, many options and we
get what for that trade-off? A simpler way to implement variance for the
object-type only? No thanks.

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Michał Brzuchalski]

Thank your Levi for your explanation.

2017-05-17 16:47 GMT+02:00 Levi Morrison :

>
>
> On Wed, May 17, 2017 at 4:34 AM, Michał Brzuchalski <
> mic...@brzuchalski.com> wrote:
>
>> Hi everyone,
>>
>> I would like to put Object Type RFC up to a vote for inclusion in PHP 7.2.
>>
>> Previously there were some concerns about adding named types in the
>> future,
>> but we came to the conclusion that each of them can be solved if there are
>> proposals in the future.
>>
>> Voting starts today, 2017-05-17, and will close after two weeks on the
>> Wednesday 2017-05-31 at midnight.
>>
>> The RFC and voting widget can be found here: https://wiki.php.net/
>> rfc/object-typehint 
>>
>> The vote is a straight Yes/No vote for accepting the RFC and merging the
>> patch which require 2/3 majority.
>> The additional vote is also a straight Yes/No vote for accepting variance
>> behaviour on the object type which also require 2/3 majority.
>>
>> Thanks!
>> --
>> regards / pozdrawiam,
>> --
>> Michał Brzuchalski
>> about.me/brzuchal
>> brzuchalski.com
>>
>
> An emphatic "no" on variance for me. This is for two over-arching reasons:
>
>   1. Object variance should be implemented when we have generalized
> variance for all types. By special casing it now we open ourselves to the
> possibility that its implementation or semantics will differ from the
> generalized solution.
>
>   2. The way it is implemented prevents us from adding new types which are
> not objects. The reason is that the way this is implemented it just assumes
> that an unknown type is an object type. If we add a feature such as an
> enumerations (enums) this assumption probably breaks and cannot be fixed
> while maintaining BC as it would almost certainly need to trigger an
> autoload.
>
>
We were thinking about enumerations and generally IMHO, they can be
implemented as objects though. Especially when taking Java pattern
http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html when dealing
with enumeration means dealing with a special purpose and special kind of
objects, which are IMO more powerful with methods which can implement some
behaviour.



> Given these two points I think it's unwise to implement variance as
> outlined. I highly encourage other voters to vote against that portion of
> the RFC.
>
> -
>
> Lastly, I want to thank Dan and Michal for working on this RFC as an
> object type even without variance would have been useful for me in the past.
>



-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Sebastian Bergmann]

On 05/17/2017 04:47 PM, Levi Morrison wrote:

An emphatic "no" on variance for me. This is for two over-arching reasons:


Thank you, Levi, for the explanation of your "no" vote on object 
variance. That saved me quite a bit of typing :-)


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Andrey Andreev]

Hi,

On Wed, May 17, 2017 at 5:47 PM, Levi Morrison  wrote:
>
>   1. Object variance should be implemented when we have generalized
> variance for all types. By special casing it now we open ourselves to the
> possibility that its implementation or semantics will differ from the
> generalized solution.
>

That's a very good point.

It may even decide how variance works in all of PHP, "because consistency".

Cheers,
Andrey.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

[Levi Morrison]

On Wed, May 17, 2017 at 4:34 AM, Michał Brzuchalski 
wrote:

> Hi everyone,
>
> I would like to put Object Type RFC up to a vote for inclusion in PHP 7.2.
>
> Previously there were some concerns about adding named types in the future,
> but we came to the conclusion that each of them can be solved if there are
> proposals in the future.
>
> Voting starts today, 2017-05-17, and will close after two weeks on the
> Wednesday 2017-05-31 at midnight.
>
> The RFC and voting widget can be found here: https://wiki.php.net/
> rfc/object-typehint
>
> The vote is a straight Yes/No vote for accepting the RFC and merging the
> patch which require 2/3 majority.
> The additional vote is also a straight Yes/No vote for accepting variance
> behaviour on the object type which also require 2/3 majority.
>
> Thanks!
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>

An emphatic "no" on variance for me. This is for two over-arching reasons:

  1. Object variance should be implemented when we have generalized
variance for all types. By special casing it now we open ourselves to the
possibility that its implementation or semantics will differ from the
generalized solution.

  2. The way it is implemented prevents us from adding new types which are
not objects. The reason is that the way this is implemented it just assumes
that an unknown type is an object type. If we add a feature such as an
enumerations (enums) this assumption probably breaks and cannot be fixed
while maintaining BC as it would almost certainly need to trigger an
autoload.

Given these two points I think it's unwise to implement variance as
outlined. I highly encourage other voters to vote against that portion of
the RFC.

-

Lastly, I want to thank Dan and Michal for working on this RFC as an object
type even without variance would have been useful for me in the past.

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Michał Brzuchalski]

Yes, function/method arguments should be contravariant.

I'm sorry I haven't got caught anyone to review after Joe's patch.

I promise to remember about that next time.

2016-11-14 10:20 GMT+01:00 Josh Di Fabio :

> On Mon, Nov 14, 2016 at 8:54 AM Michał Brzuchalski 
> wrote:
>
>> Hi All,
>>
>> Id' like to anounce voting reset - will end in two weeks on 28.11.2016 at
>> midnight and requires 2/3 majority as previously.
>>
>> There were improvements suggested by Joe Watkins and earlier by Nikita
>> Popov to the patch.
>>
>> Those improvements are described on RFC under "Covariance" section
>> https://wiki.php.net/rfc/object-typehint#covariance
>
> This section describes covariance of method arguments. Is this a mistake?
> Should this be contravariance? Covariant arguments go against LSP.
>
>>
>> It means any `object` typehint or return type can be narrowed to more
>> specified type (class name) similar to `iterable` pseudo-type but behaves
>> covariant (more general type can be raplaced with narrowed one).
>>
>> P.S. I hope this improvement will bring more positive votes.
>>
>> regards,
>> --
>> Michał
>>
>> 2016-11-10 13:30 GMT+01:00 Joe Watkins :
>>
>> > Levi,
>> >
>> > You are assuming it would *need* to be removed :)
>> >
>> > Future RFC's must deal with the engine as they find it, as this RFC
>> > has done.
>> >
>> > If it is true that this would prohibit enums being non-objects, and
>> > I'm not certain that it does, then enums would have to be objects, if
>> > that's how they find the engine.
>> >
>> > If your only concern is about a non-existent feature, then maybe
>> > you're concern can be alleviated by the non-existent JIT (which does
>> > partially exist): With a JIT, it doesn't much matter what represents
>> enums
>> > anyway.
>> >
>> > These are problems for the future, not today.
>> >
>> > Cheers
>> > Joe
>> >
>> > On Thu, Nov 10, 2016 at 12:20 PM, Levi Morrison  wrote:
>> >
>> >> On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins 
>> >> wrote:
>> >> > Morning Levi,
>> >> >
>> >> >> There is a future compatibility issue of this same type with
>> `object`:
>> >> >
>> >> > If that is an issue, it is for future RFC's to deal with.
>> >> >
>> >> > Cheers
>> >> > Joe
>> >> >
>> >> >
>> >> > On Thu, Nov 10, 2016 at 12:12 PM, Levi Morrison 
>> wrote:
>> >> >>
>> >> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller 
>> wrote:
>> >> >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker > >:
>> >> >> >
>> >> >> >> On 09.11.2016 at 17:28, Joe Watkins wrote:
>> >> >> >>
>> >> >> >> > I want to explain why I voted no on this:
>> >> >> >> >
>> >> >> >> > I think it's significantly less useful without variance,
>> >> variance
>> >> >> >> > is
>> >> >> >> > something that is usually difficult to achieve in PHP, but not
>> for
>> >> >> >> > this
>> >> >> >> > feature in particular.
>> >> >> >>
>> >> >> >> Can you please elaborate what you mean with variance?  I see some
>> >> >> >> practical use cases for covariance of a method with return type
>> >> object,
>> >> >> >> but I don't see how contravariance could be achieved for
>> parameters
>> >> of
>> >> >> >> type object.
>> >> >> >>
>> >> >> >> If your suggestion is only about invariance of object return
>> types,
>> >> I'm
>> >> >> >> not sure if this very special case would make sense (for
>> consistency
>> >> >> >> reasons).
>> >> >> >>
>> >> >> >
>> >> >> > We already have it for iterable -> array. We would have it for all
>> >> other
>> >> >> > types if there wouldn't be an implementation issue.
>> >> >> >
>> >> >> > Regards, Niklas
>> >> >> >
>> >> >> > Cheers,
>> >> >> >> Christoph
>> >> >> >>
>> >> >> >> > I absolutely want it, but I want it to be properly useful.
>> >> >> >> >
>> >> >> >> > If the RFC were halted and patched to include variance,
>> I'd +1
>> >> >> >> > it.
>> >> >> >> >
>> >> >> >> > Cheers
>> >> >> >> > Joe
>> >> >> >> >
>> >> >> >> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
>> >> >> >> > > >> >> >> .com>
>> >> >> >> > wrote:
>> >> >> >> >
>> >> >> >> >> Hi everyone,
>> >> >> >> >>
>> >> >> >> >> Two weeks have passed since this RFC was put to discussion
>> here.
>> >> >> >> >>
>> >> >> >> >> Therefore, I'm going to put it to a vote for inclusion in PHP
>> >> 7.2.
>> >> >> >> >>
>> >> >> >> >> Voting starts today, 2016-11-06, and will close after two
>> weeks
>> >> on
>> >> >> >> >> the
>> >> >> >> >> Sunday 2016-11-20 at midnight.
>> >> >> >> >>
>> >> >> >> >> The RFC and voting widget can be found here:
>> >> >> >> >> https://wiki.php.net/rfc/object-typehint
>> >> >> >> >>
>> >> >> >> >> It's a normal 2/3 majority required vote.
>> >> >> >> >>
>> >> >> >> >> Thanks!
>> >> >> >> >> --
>> >> >> >> >> regards / pozdrawiam,
>> >> >> >> >> --
>> >> >> >> >> Michał Brzuchalski
>> >> >> >> >> about.me/brzuchal
>> >> 

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Josh Di Fabio]

On Mon, Nov 14, 2016 at 8:54 AM Michał Brzuchalski 
wrote:

> Hi All,
>
> Id' like to anounce voting reset - will end in two weeks on 28.11.2016 at
> midnight and requires 2/3 majority as previously.
>
> There were improvements suggested by Joe Watkins and earlier by Nikita
> Popov to the patch.
>
> Those improvements are described on RFC under "Covariance" section
> https://wiki.php.net/rfc/object-typehint#covariance

This section describes covariance of method arguments. Is this a mistake?
Should this be contravariance? Covariant arguments go against LSP.

>
> It means any `object` typehint or return type can be narrowed to more
> specified type (class name) similar to `iterable` pseudo-type but behaves
> covariant (more general type can be raplaced with narrowed one).
>
> P.S. I hope this improvement will bring more positive votes.
>
> regards,
> --
> Michał
>
> 2016-11-10 13:30 GMT+01:00 Joe Watkins :
>
> > Levi,
> >
> > You are assuming it would *need* to be removed :)
> >
> > Future RFC's must deal with the engine as they find it, as this RFC
> > has done.
> >
> > If it is true that this would prohibit enums being non-objects, and
> > I'm not certain that it does, then enums would have to be objects, if
> > that's how they find the engine.
> >
> > If your only concern is about a non-existent feature, then maybe
> > you're concern can be alleviated by the non-existent JIT (which does
> > partially exist): With a JIT, it doesn't much matter what represents
> enums
> > anyway.
> >
> > These are problems for the future, not today.
> >
> > Cheers
> > Joe
> >
> > On Thu, Nov 10, 2016 at 12:20 PM, Levi Morrison  wrote:
> >
> >> On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins 
> >> wrote:
> >> > Morning Levi,
> >> >
> >> >> There is a future compatibility issue of this same type with
> `object`:
> >> >
> >> > If that is an issue, it is for future RFC's to deal with.
> >> >
> >> > Cheers
> >> > Joe
> >> >
> >> >
> >> > On Thu, Nov 10, 2016 at 12:12 PM, Levi Morrison 
> wrote:
> >> >>
> >> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller 
> wrote:
> >> >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker  >:
> >> >> >
> >> >> >> On 09.11.2016 at 17:28, Joe Watkins wrote:
> >> >> >>
> >> >> >> > I want to explain why I voted no on this:
> >> >> >> >
> >> >> >> > I think it's significantly less useful without variance,
> >> variance
> >> >> >> > is
> >> >> >> > something that is usually difficult to achieve in PHP, but not
> for
> >> >> >> > this
> >> >> >> > feature in particular.
> >> >> >>
> >> >> >> Can you please elaborate what you mean with variance?  I see some
> >> >> >> practical use cases for covariance of a method with return type
> >> object,
> >> >> >> but I don't see how contravariance could be achieved for
> parameters
> >> of
> >> >> >> type object.
> >> >> >>
> >> >> >> If your suggestion is only about invariance of object return
> types,
> >> I'm
> >> >> >> not sure if this very special case would make sense (for
> consistency
> >> >> >> reasons).
> >> >> >>
> >> >> >
> >> >> > We already have it for iterable -> array. We would have it for all
> >> other
> >> >> > types if there wouldn't be an implementation issue.
> >> >> >
> >> >> > Regards, Niklas
> >> >> >
> >> >> > Cheers,
> >> >> >> Christoph
> >> >> >>
> >> >> >> > I absolutely want it, but I want it to be properly useful.
> >> >> >> >
> >> >> >> > If the RFC were halted and patched to include variance, I'd
> +1
> >> >> >> > it.
> >> >> >> >
> >> >> >> > Cheers
> >> >> >> > Joe
> >> >> >> >
> >> >> >> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
> >> >> >> >  >> >> >> .com>
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> >> Hi everyone,
> >> >> >> >>
> >> >> >> >> Two weeks have passed since this RFC was put to discussion
> here.
> >> >> >> >>
> >> >> >> >> Therefore, I'm going to put it to a vote for inclusion in PHP
> >> 7.2.
> >> >> >> >>
> >> >> >> >> Voting starts today, 2016-11-06, and will close after two weeks
> >> on
> >> >> >> >> the
> >> >> >> >> Sunday 2016-11-20 at midnight.
> >> >> >> >>
> >> >> >> >> The RFC and voting widget can be found here:
> >> >> >> >> https://wiki.php.net/rfc/object-typehint
> >> >> >> >>
> >> >> >> >> It's a normal 2/3 majority required vote.
> >> >> >> >>
> >> >> >> >> Thanks!
> >> >> >> >> --
> >> >> >> >> regards / pozdrawiam,
> >> >> >> >> --
> >> >> >> >> Michał Brzuchalski
> >> >> >> >> about.me/brzuchal
> >> >> >> >> brzuchalski.com
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> PHP Internals - PHP Runtime Development Mailing List
> >> >> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >> >> >>
> >> >> >>
> >> >>
> >> >> In a return type context `iterable` can be changed to `Traversable`
> or
> >> >> `array`; it cannot be changed to `Collection` as we cannot 

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Joe Watkins]

Sorry people, my fault :(

On Mon, Nov 14, 2016 at 9:16 AM, Michał Brzuchalski 
wrote:

> Hi All,
>
> again with bad news, sorry for the mess, the argument override is allowed
> in wrong direction what beaks Liskov's principle so need to stop it again.
> Hold on for a while, don't loose faith.
>
> regards,
> Michał
>
> 2016-11-14 9:53 GMT+01:00 Michał Brzuchalski :
>
> > Hi All,
> >
> > Id' like to anounce voting reset - will end in two weeks on 28.11.2016 at
> > midnight and requires 2/3 majority as previously.
> >
> > There were improvements suggested by Joe Watkins and earlier by Nikita
> > Popov to the patch.
> >
> > Those improvements are described on RFC under "Covariance" section
> > https://wiki.php.net/rfc/object-typehint#covariance
> >
> > It means any `object` typehint or return type can be narrowed to more
> > specified type (class name) similar to `iterable` pseudo-type but behaves
> > covariant (more general type can be raplaced with narrowed one).
> >
> > P.S. I hope this improvement will bring more positive votes.
> >
> > regards,
> > --
> > Michał
> >
> > 2016-11-10 13:30 GMT+01:00 Joe Watkins :
> >
> >> Levi,
> >>
> >> You are assuming it would *need* to be removed :)
> >>
> >> Future RFC's must deal with the engine as they find it, as this RFC
> >> has done.
> >>
> >> If it is true that this would prohibit enums being non-objects, and
> >> I'm not certain that it does, then enums would have to be objects, if
> >> that's how they find the engine.
> >>
> >> If your only concern is about a non-existent feature, then maybe
> >> you're concern can be alleviated by the non-existent JIT (which does
> >> partially exist): With a JIT, it doesn't much matter what represents
> enums
> >> anyway.
> >>
> >> These are problems for the future, not today.
> >>
> >> Cheers
> >> Joe
> >>
> >> On Thu, Nov 10, 2016 at 12:20 PM, Levi Morrison  wrote:
> >>
> >>> On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins 
> >>> wrote:
> >>> > Morning Levi,
> >>> >
> >>> >> There is a future compatibility issue of this same type with
> `object`:
> >>> >
> >>> > If that is an issue, it is for future RFC's to deal with.
> >>> >
> >>> > Cheers
> >>> > Joe
> >>> >
> >>> >
> >>> > On Thu, Nov 10, 2016 at 12:12 PM, Levi Morrison 
> wrote:
> >>> >>
> >>> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller 
> >>> wrote:
> >>> >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker  >:
> >>> >> >
> >>> >> >> On 09.11.2016 at 17:28, Joe Watkins wrote:
> >>> >> >>
> >>> >> >> > I want to explain why I voted no on this:
> >>> >> >> >
> >>> >> >> > I think it's significantly less useful without variance,
> >>> variance
> >>> >> >> > is
> >>> >> >> > something that is usually difficult to achieve in PHP, but not
> >>> for
> >>> >> >> > this
> >>> >> >> > feature in particular.
> >>> >> >>
> >>> >> >> Can you please elaborate what you mean with variance?  I see some
> >>> >> >> practical use cases for covariance of a method with return type
> >>> object,
> >>> >> >> but I don't see how contravariance could be achieved for
> >>> parameters of
> >>> >> >> type object.
> >>> >> >>
> >>> >> >> If your suggestion is only about invariance of object return
> >>> types, I'm
> >>> >> >> not sure if this very special case would make sense (for
> >>> consistency
> >>> >> >> reasons).
> >>> >> >>
> >>> >> >
> >>> >> > We already have it for iterable -> array. We would have it for all
> >>> other
> >>> >> > types if there wouldn't be an implementation issue.
> >>> >> >
> >>> >> > Regards, Niklas
> >>> >> >
> >>> >> > Cheers,
> >>> >> >> Christoph
> >>> >> >>
> >>> >> >> > I absolutely want it, but I want it to be properly useful.
> >>> >> >> >
> >>> >> >> > If the RFC were halted and patched to include variance, I'd
> >>> +1
> >>> >> >> > it.
> >>> >> >> >
> >>> >> >> > Cheers
> >>> >> >> > Joe
> >>> >> >> >
> >>> >> >> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
> >>> >> >> >  >>> >> >> .com>
> >>> >> >> > wrote:
> >>> >> >> >
> >>> >> >> >> Hi everyone,
> >>> >> >> >>
> >>> >> >> >> Two weeks have passed since this RFC was put to discussion
> here.
> >>> >> >> >>
> >>> >> >> >> Therefore, I'm going to put it to a vote for inclusion in PHP
> >>> 7.2.
> >>> >> >> >>
> >>> >> >> >> Voting starts today, 2016-11-06, and will close after two
> weeks
> >>> on
> >>> >> >> >> the
> >>> >> >> >> Sunday 2016-11-20 at midnight.
> >>> >> >> >>
> >>> >> >> >> The RFC and voting widget can be found here:
> >>> >> >> >> https://wiki.php.net/rfc/object-typehint
> >>> >> >> >>
> >>> >> >> >> It's a normal 2/3 majority required vote.
> >>> >> >> >>
> >>> >> >> >> Thanks!
> >>> >> >> >> --
> >>> >> >> >> regards / pozdrawiam,
> >>> >> >> >> --
> >>> >> >> >> Michał Brzuchalski
> >>> >> >> >> about.me/brzuchal
> >>> >> >> >> brzuchalski.com
> >>> >> 

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Michał Brzuchalski]

Hi All,

again with bad news, sorry for the mess, the argument override is allowed
in wrong direction what beaks Liskov's principle so need to stop it again.
Hold on for a while, don't loose faith.

regards,
Michał

2016-11-14 9:53 GMT+01:00 Michał Brzuchalski :

> Hi All,
>
> Id' like to anounce voting reset - will end in two weeks on 28.11.2016 at
> midnight and requires 2/3 majority as previously.
>
> There were improvements suggested by Joe Watkins and earlier by Nikita
> Popov to the patch.
>
> Those improvements are described on RFC under "Covariance" section
> https://wiki.php.net/rfc/object-typehint#covariance
>
> It means any `object` typehint or return type can be narrowed to more
> specified type (class name) similar to `iterable` pseudo-type but behaves
> covariant (more general type can be raplaced with narrowed one).
>
> P.S. I hope this improvement will bring more positive votes.
>
> regards,
> --
> Michał
>
> 2016-11-10 13:30 GMT+01:00 Joe Watkins :
>
>> Levi,
>>
>> You are assuming it would *need* to be removed :)
>>
>> Future RFC's must deal with the engine as they find it, as this RFC
>> has done.
>>
>> If it is true that this would prohibit enums being non-objects, and
>> I'm not certain that it does, then enums would have to be objects, if
>> that's how they find the engine.
>>
>> If your only concern is about a non-existent feature, then maybe
>> you're concern can be alleviated by the non-existent JIT (which does
>> partially exist): With a JIT, it doesn't much matter what represents enums
>> anyway.
>>
>> These are problems for the future, not today.
>>
>> Cheers
>> Joe
>>
>> On Thu, Nov 10, 2016 at 12:20 PM, Levi Morrison  wrote:
>>
>>> On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins 
>>> wrote:
>>> > Morning Levi,
>>> >
>>> >> There is a future compatibility issue of this same type with `object`:
>>> >
>>> > If that is an issue, it is for future RFC's to deal with.
>>> >
>>> > Cheers
>>> > Joe
>>> >
>>> >
>>> > On Thu, Nov 10, 2016 at 12:12 PM, Levi Morrison  wrote:
>>> >>
>>> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller 
>>> wrote:
>>> >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
>>> >> >
>>> >> >> On 09.11.2016 at 17:28, Joe Watkins wrote:
>>> >> >>
>>> >> >> > I want to explain why I voted no on this:
>>> >> >> >
>>> >> >> > I think it's significantly less useful without variance,
>>> variance
>>> >> >> > is
>>> >> >> > something that is usually difficult to achieve in PHP, but not
>>> for
>>> >> >> > this
>>> >> >> > feature in particular.
>>> >> >>
>>> >> >> Can you please elaborate what you mean with variance?  I see some
>>> >> >> practical use cases for covariance of a method with return type
>>> object,
>>> >> >> but I don't see how contravariance could be achieved for
>>> parameters of
>>> >> >> type object.
>>> >> >>
>>> >> >> If your suggestion is only about invariance of object return
>>> types, I'm
>>> >> >> not sure if this very special case would make sense (for
>>> consistency
>>> >> >> reasons).
>>> >> >>
>>> >> >
>>> >> > We already have it for iterable -> array. We would have it for all
>>> other
>>> >> > types if there wouldn't be an implementation issue.
>>> >> >
>>> >> > Regards, Niklas
>>> >> >
>>> >> > Cheers,
>>> >> >> Christoph
>>> >> >>
>>> >> >> > I absolutely want it, but I want it to be properly useful.
>>> >> >> >
>>> >> >> > If the RFC were halted and patched to include variance, I'd
>>> +1
>>> >> >> > it.
>>> >> >> >
>>> >> >> > Cheers
>>> >> >> > Joe
>>> >> >> >
>>> >> >> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
>>> >> >> > >> >> >> .com>
>>> >> >> > wrote:
>>> >> >> >
>>> >> >> >> Hi everyone,
>>> >> >> >>
>>> >> >> >> Two weeks have passed since this RFC was put to discussion here.
>>> >> >> >>
>>> >> >> >> Therefore, I'm going to put it to a vote for inclusion in PHP
>>> 7.2.
>>> >> >> >>
>>> >> >> >> Voting starts today, 2016-11-06, and will close after two weeks
>>> on
>>> >> >> >> the
>>> >> >> >> Sunday 2016-11-20 at midnight.
>>> >> >> >>
>>> >> >> >> The RFC and voting widget can be found here:
>>> >> >> >> https://wiki.php.net/rfc/object-typehint
>>> >> >> >>
>>> >> >> >> It's a normal 2/3 majority required vote.
>>> >> >> >>
>>> >> >> >> Thanks!
>>> >> >> >> --
>>> >> >> >> regards / pozdrawiam,
>>> >> >> >> --
>>> >> >> >> Michał Brzuchalski
>>> >> >> >> about.me/brzuchal
>>> >> >> >> brzuchalski.com
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> PHP Internals - PHP Runtime Development Mailing List
>>> >> >> To unsubscribe, visit: http://www.php.net/unsub.php
>>> >> >>
>>> >> >>
>>> >>
>>> >> In a return type context `iterable` can be changed to `Traversable` or
>>> >> `array`; it cannot be changed to `Collection` as we cannot guarantee
>>> >> at compile-time that `Collection` implements 

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Michał Brzuchalski]

Hi All,

Id' like to anounce voting reset - will end in two weeks on 28.11.2016 at
midnight and requires 2/3 majority as previously.

There were improvements suggested by Joe Watkins and earlier by Nikita
Popov to the patch.

Those improvements are described on RFC under "Covariance" section
https://wiki.php.net/rfc/object-typehint#covariance

It means any `object` typehint or return type can be narrowed to more
specified type (class name) similar to `iterable` pseudo-type but behaves
covariant (more general type can be raplaced with narrowed one).

P.S. I hope this improvement will bring more positive votes.

regards,
--
Michał

2016-11-10 13:30 GMT+01:00 Joe Watkins :

> Levi,
>
> You are assuming it would *need* to be removed :)
>
> Future RFC's must deal with the engine as they find it, as this RFC
> has done.
>
> If it is true that this would prohibit enums being non-objects, and
> I'm not certain that it does, then enums would have to be objects, if
> that's how they find the engine.
>
> If your only concern is about a non-existent feature, then maybe
> you're concern can be alleviated by the non-existent JIT (which does
> partially exist): With a JIT, it doesn't much matter what represents enums
> anyway.
>
> These are problems for the future, not today.
>
> Cheers
> Joe
>
> On Thu, Nov 10, 2016 at 12:20 PM, Levi Morrison  wrote:
>
>> On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins 
>> wrote:
>> > Morning Levi,
>> >
>> >> There is a future compatibility issue of this same type with `object`:
>> >
>> > If that is an issue, it is for future RFC's to deal with.
>> >
>> > Cheers
>> > Joe
>> >
>> >
>> > On Thu, Nov 10, 2016 at 12:12 PM, Levi Morrison  wrote:
>> >>
>> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller  wrote:
>> >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
>> >> >
>> >> >> On 09.11.2016 at 17:28, Joe Watkins wrote:
>> >> >>
>> >> >> > I want to explain why I voted no on this:
>> >> >> >
>> >> >> > I think it's significantly less useful without variance,
>> variance
>> >> >> > is
>> >> >> > something that is usually difficult to achieve in PHP, but not for
>> >> >> > this
>> >> >> > feature in particular.
>> >> >>
>> >> >> Can you please elaborate what you mean with variance?  I see some
>> >> >> practical use cases for covariance of a method with return type
>> object,
>> >> >> but I don't see how contravariance could be achieved for parameters
>> of
>> >> >> type object.
>> >> >>
>> >> >> If your suggestion is only about invariance of object return types,
>> I'm
>> >> >> not sure if this very special case would make sense (for consistency
>> >> >> reasons).
>> >> >>
>> >> >
>> >> > We already have it for iterable -> array. We would have it for all
>> other
>> >> > types if there wouldn't be an implementation issue.
>> >> >
>> >> > Regards, Niklas
>> >> >
>> >> > Cheers,
>> >> >> Christoph
>> >> >>
>> >> >> > I absolutely want it, but I want it to be properly useful.
>> >> >> >
>> >> >> > If the RFC were halted and patched to include variance, I'd +1
>> >> >> > it.
>> >> >> >
>> >> >> > Cheers
>> >> >> > Joe
>> >> >> >
>> >> >> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
>> >> >> > > >> >> .com>
>> >> >> > wrote:
>> >> >> >
>> >> >> >> Hi everyone,
>> >> >> >>
>> >> >> >> Two weeks have passed since this RFC was put to discussion here.
>> >> >> >>
>> >> >> >> Therefore, I'm going to put it to a vote for inclusion in PHP
>> 7.2.
>> >> >> >>
>> >> >> >> Voting starts today, 2016-11-06, and will close after two weeks
>> on
>> >> >> >> the
>> >> >> >> Sunday 2016-11-20 at midnight.
>> >> >> >>
>> >> >> >> The RFC and voting widget can be found here:
>> >> >> >> https://wiki.php.net/rfc/object-typehint
>> >> >> >>
>> >> >> >> It's a normal 2/3 majority required vote.
>> >> >> >>
>> >> >> >> Thanks!
>> >> >> >> --
>> >> >> >> regards / pozdrawiam,
>> >> >> >> --
>> >> >> >> Michał Brzuchalski
>> >> >> >> about.me/brzuchal
>> >> >> >> brzuchalski.com
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> PHP Internals - PHP Runtime Development Mailing List
>> >> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >> >>
>> >> >>
>> >>
>> >> In a return type context `iterable` can be changed to `Traversable` or
>> >> `array`; it cannot be changed to `Collection` as we cannot guarantee
>> >> at compile-time that `Collection` implements Traversable.
>> >>
>> >> There is a future compatibility issue of this same type with `object`:
>> >> right now the only user-definable types are objects. However, enums
>> >> are an often requested feature and they may not be objects. Thus we
>> >> wouldn't be able to guarantee that `Foo` is an object. There is a
>> >> draft RFC with a patch for enums and expect it will come to a
>> >> discussion soon, so I don't think we'll have to wait very long to know
>> >> the 

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Joe Watkins]

Levi,

You are assuming it would *need* to be removed :)

Future RFC's must deal with the engine as they find it, as this RFC has
done.

If it is true that this would prohibit enums being non-objects, and I'm
not certain that it does, then enums would have to be objects, if that's
how they find the engine.

If your only concern is about a non-existent feature, then maybe you're
concern can be alleviated by the non-existent JIT (which does partially
exist): With a JIT, it doesn't much matter what represents enums anyway.

These are problems for the future, not today.

Cheers
Joe

On Thu, Nov 10, 2016 at 12:20 PM, Levi Morrison  wrote:

> On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins 
> wrote:
> > Morning Levi,
> >
> >> There is a future compatibility issue of this same type with `object`:
> >
> > If that is an issue, it is for future RFC's to deal with.
> >
> > Cheers
> > Joe
> >
> >
> > On Thu, Nov 10, 2016 at 12:12 PM, Levi Morrison  wrote:
> >>
> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller  wrote:
> >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
> >> >
> >> >> On 09.11.2016 at 17:28, Joe Watkins wrote:
> >> >>
> >> >> > I want to explain why I voted no on this:
> >> >> >
> >> >> > I think it's significantly less useful without variance,
> variance
> >> >> > is
> >> >> > something that is usually difficult to achieve in PHP, but not for
> >> >> > this
> >> >> > feature in particular.
> >> >>
> >> >> Can you please elaborate what you mean with variance?  I see some
> >> >> practical use cases for covariance of a method with return type
> object,
> >> >> but I don't see how contravariance could be achieved for parameters
> of
> >> >> type object.
> >> >>
> >> >> If your suggestion is only about invariance of object return types,
> I'm
> >> >> not sure if this very special case would make sense (for consistency
> >> >> reasons).
> >> >>
> >> >
> >> > We already have it for iterable -> array. We would have it for all
> other
> >> > types if there wouldn't be an implementation issue.
> >> >
> >> > Regards, Niklas
> >> >
> >> > Cheers,
> >> >> Christoph
> >> >>
> >> >> > I absolutely want it, but I want it to be properly useful.
> >> >> >
> >> >> > If the RFC were halted and patched to include variance, I'd +1
> >> >> > it.
> >> >> >
> >> >> > Cheers
> >> >> > Joe
> >> >> >
> >> >> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
> >> >> >  >> >> .com>
> >> >> > wrote:
> >> >> >
> >> >> >> Hi everyone,
> >> >> >>
> >> >> >> Two weeks have passed since this RFC was put to discussion here.
> >> >> >>
> >> >> >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
> >> >> >>
> >> >> >> Voting starts today, 2016-11-06, and will close after two weeks on
> >> >> >> the
> >> >> >> Sunday 2016-11-20 at midnight.
> >> >> >>
> >> >> >> The RFC and voting widget can be found here:
> >> >> >> https://wiki.php.net/rfc/object-typehint
> >> >> >>
> >> >> >> It's a normal 2/3 majority required vote.
> >> >> >>
> >> >> >> Thanks!
> >> >> >> --
> >> >> >> regards / pozdrawiam,
> >> >> >> --
> >> >> >> Michał Brzuchalski
> >> >> >> about.me/brzuchal
> >> >> >> brzuchalski.com
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> PHP Internals - PHP Runtime Development Mailing List
> >> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >> >>
> >> >>
> >>
> >> In a return type context `iterable` can be changed to `Traversable` or
> >> `array`; it cannot be changed to `Collection` as we cannot guarantee
> >> at compile-time that `Collection` implements Traversable.
> >>
> >> There is a future compatibility issue of this same type with `object`:
> >> right now the only user-definable types are objects. However, enums
> >> are an often requested feature and they may not be objects. Thus we
> >> wouldn't be able to guarantee that `Foo` is an object. There is a
> >> draft RFC with a patch for enums and expect it will come to a
> >> discussion soon, so I don't think we'll have to wait very long to know
> >> the answer here.
> >
> >
>
> I strongly disagree here; once we add `object` return type covariance
> it cannot easily be removed.
>

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Levi Morrison]

On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins  wrote:
> Morning Levi,
>
>> There is a future compatibility issue of this same type with `object`:
>
> If that is an issue, it is for future RFC's to deal with.
>
> Cheers
> Joe
>
>
> On Thu, Nov 10, 2016 at 12:12 PM, Levi Morrison  wrote:
>>
>> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller  wrote:
>> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
>> >
>> >> On 09.11.2016 at 17:28, Joe Watkins wrote:
>> >>
>> >> > I want to explain why I voted no on this:
>> >> >
>> >> > I think it's significantly less useful without variance, variance
>> >> > is
>> >> > something that is usually difficult to achieve in PHP, but not for
>> >> > this
>> >> > feature in particular.
>> >>
>> >> Can you please elaborate what you mean with variance?  I see some
>> >> practical use cases for covariance of a method with return type object,
>> >> but I don't see how contravariance could be achieved for parameters of
>> >> type object.
>> >>
>> >> If your suggestion is only about invariance of object return types, I'm
>> >> not sure if this very special case would make sense (for consistency
>> >> reasons).
>> >>
>> >
>> > We already have it for iterable -> array. We would have it for all other
>> > types if there wouldn't be an implementation issue.
>> >
>> > Regards, Niklas
>> >
>> > Cheers,
>> >> Christoph
>> >>
>> >> > I absolutely want it, but I want it to be properly useful.
>> >> >
>> >> > If the RFC were halted and patched to include variance, I'd +1
>> >> > it.
>> >> >
>> >> > Cheers
>> >> > Joe
>> >> >
>> >> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
>> >> > > >> .com>
>> >> > wrote:
>> >> >
>> >> >> Hi everyone,
>> >> >>
>> >> >> Two weeks have passed since this RFC was put to discussion here.
>> >> >>
>> >> >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
>> >> >>
>> >> >> Voting starts today, 2016-11-06, and will close after two weeks on
>> >> >> the
>> >> >> Sunday 2016-11-20 at midnight.
>> >> >>
>> >> >> The RFC and voting widget can be found here:
>> >> >> https://wiki.php.net/rfc/object-typehint
>> >> >>
>> >> >> It's a normal 2/3 majority required vote.
>> >> >>
>> >> >> Thanks!
>> >> >> --
>> >> >> regards / pozdrawiam,
>> >> >> --
>> >> >> Michał Brzuchalski
>> >> >> about.me/brzuchal
>> >> >> brzuchalski.com
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> PHP Internals - PHP Runtime Development Mailing List
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>
>> >>
>>
>> In a return type context `iterable` can be changed to `Traversable` or
>> `array`; it cannot be changed to `Collection` as we cannot guarantee
>> at compile-time that `Collection` implements Traversable.
>>
>> There is a future compatibility issue of this same type with `object`:
>> right now the only user-definable types are objects. However, enums
>> are an often requested feature and they may not be objects. Thus we
>> wouldn't be able to guarantee that `Foo` is an object. There is a
>> draft RFC with a patch for enums and expect it will come to a
>> discussion soon, so I don't think we'll have to wait very long to know
>> the answer here.
>
>

I strongly disagree here; once we add `object` return type covariance
it cannot easily be removed.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Joe Watkins]

Morning Levi,

> There is a future compatibility issue of this same type with `object`:

If that is an issue, it is for future RFC's to deal with.

Cheers
Joe


On Thu, Nov 10, 2016 at 12:12 PM, Levi Morrison  wrote:

> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller  wrote:
> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
> >
> >> On 09.11.2016 at 17:28, Joe Watkins wrote:
> >>
> >> > I want to explain why I voted no on this:
> >> >
> >> > I think it's significantly less useful without variance, variance
> is
> >> > something that is usually difficult to achieve in PHP, but not for
> this
> >> > feature in particular.
> >>
> >> Can you please elaborate what you mean with variance?  I see some
> >> practical use cases for covariance of a method with return type object,
> >> but I don't see how contravariance could be achieved for parameters of
> >> type object.
> >>
> >> If your suggestion is only about invariance of object return types, I'm
> >> not sure if this very special case would make sense (for consistency
> >> reasons).
> >>
> >
> > We already have it for iterable -> array. We would have it for all other
> > types if there wouldn't be an implementation issue.
> >
> > Regards, Niklas
> >
> > Cheers,
> >> Christoph
> >>
> >> > I absolutely want it, but I want it to be properly useful.
> >> >
> >> > If the RFC were halted and patched to include variance, I'd +1 it.
> >> >
> >> > Cheers
> >> > Joe
> >> >
> >> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
>  >> .com>
> >> > wrote:
> >> >
> >> >> Hi everyone,
> >> >>
> >> >> Two weeks have passed since this RFC was put to discussion here.
> >> >>
> >> >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
> >> >>
> >> >> Voting starts today, 2016-11-06, and will close after two weeks on
> the
> >> >> Sunday 2016-11-20 at midnight.
> >> >>
> >> >> The RFC and voting widget can be found here:
> >> >> https://wiki.php.net/rfc/object-typehint
> >> >>
> >> >> It's a normal 2/3 majority required vote.
> >> >>
> >> >> Thanks!
> >> >> --
> >> >> regards / pozdrawiam,
> >> >> --
> >> >> Michał Brzuchalski
> >> >> about.me/brzuchal
> >> >> brzuchalski.com
> >> >>
> >> >
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
> In a return type context `iterable` can be changed to `Traversable` or
> `array`; it cannot be changed to `Collection` as we cannot guarantee
> at compile-time that `Collection` implements Traversable.
>
> There is a future compatibility issue of this same type with `object`:
> right now the only user-definable types are objects. However, enums
> are an often requested feature and they may not be objects. Thus we
> wouldn't be able to guarantee that `Foo` is an object. There is a
> draft RFC with a patch for enums and expect it will come to a
> discussion soon, so I don't think we'll have to wait very long to know
> the answer here.
>

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Levi Morrison]

On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller  wrote:
> 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
>
>> On 09.11.2016 at 17:28, Joe Watkins wrote:
>>
>> > I want to explain why I voted no on this:
>> >
>> > I think it's significantly less useful without variance, variance is
>> > something that is usually difficult to achieve in PHP, but not for this
>> > feature in particular.
>>
>> Can you please elaborate what you mean with variance?  I see some
>> practical use cases for covariance of a method with return type object,
>> but I don't see how contravariance could be achieved for parameters of
>> type object.
>>
>> If your suggestion is only about invariance of object return types, I'm
>> not sure if this very special case would make sense (for consistency
>> reasons).
>>
>
> We already have it for iterable -> array. We would have it for all other
> types if there wouldn't be an implementation issue.
>
> Regards, Niklas
>
> Cheers,
>> Christoph
>>
>> > I absolutely want it, but I want it to be properly useful.
>> >
>> > If the RFC were halted and patched to include variance, I'd +1 it.
>> >
>> > Cheers
>> > Joe
>> >
>> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski > .com>
>> > wrote:
>> >
>> >> Hi everyone,
>> >>
>> >> Two weeks have passed since this RFC was put to discussion here.
>> >>
>> >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
>> >>
>> >> Voting starts today, 2016-11-06, and will close after two weeks on the
>> >> Sunday 2016-11-20 at midnight.
>> >>
>> >> The RFC and voting widget can be found here:
>> >> https://wiki.php.net/rfc/object-typehint
>> >>
>> >> It's a normal 2/3 majority required vote.
>> >>
>> >> Thanks!
>> >> --
>> >> regards / pozdrawiam,
>> >> --
>> >> Michał Brzuchalski
>> >> about.me/brzuchal
>> >> brzuchalski.com
>> >>
>> >
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

In a return type context `iterable` can be changed to `Traversable` or
`array`; it cannot be changed to `Collection` as we cannot guarantee
at compile-time that `Collection` implements Traversable.

There is a future compatibility issue of this same type with `object`:
right now the only user-definable types are objects. However, enums
are an often requested feature and they may not be objects. Thus we
wouldn't be able to guarantee that `Foo` is an object. There is a
draft RFC with a patch for enums and expect it will come to a
discussion soon, so I don't think we'll have to wait very long to know
the answer here.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Peter Cowburn]

On 10 November 2016 at 10:38, Joe Watkins  wrote:

> Morning Peter,
>
> > I'll put RFC: On hold, then apply patch, draft some info in RFC and then
> set up new voting.
>
> Just a few messages up from here ...
>
> Would you prefer a new thread to make that announcement (I think it may be
> better) ?
>

No, it's fine IMO (and is the norm) to just have a message in the [VOTE]
thread. I simply missed Michał saying he was closing the vote, when
skimming the thread this morning, so thanks for pointing it out. :)


>
> Cheers
> Joe
>
> On Thu, Nov 10, 2016 at 9:52 AM, Peter Cowburn 
> wrote:
>
>>
>>
>> On 10 November 2016 at 09:11, Niklas Keller  wrote:
>>
>>> 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
>>>
>>> > On 09.11.2016 at 17:28, Joe Watkins wrote:
>>> >
>>> > > I want to explain why I voted no on this:
>>> > >
>>> > > I think it's significantly less useful without variance,
>>> variance is
>>> > > something that is usually difficult to achieve in PHP, but not for
>>> this
>>> > > feature in particular.
>>> >
>>> > Can you please elaborate what you mean with variance?  I see some
>>> > practical use cases for covariance of a method with return type object,
>>> > but I don't see how contravariance could be achieved for parameters of
>>> > type object.
>>> >
>>> > If your suggestion is only about invariance of object return types, I'm
>>> > not sure if this very special case would make sense (for consistency
>>> > reasons).
>>> >
>>>
>>> We already have it for iterable -> array. We would have it for all other
>>> types if there wouldn't be an implementation issue.
>>>
>>> Regards, Niklas
>>>
>>> Cheers,
>>> > Christoph
>>> >
>>> > > I absolutely want it, but I want it to be properly useful.
>>> > >
>>> > > If the RFC were halted and patched to include variance, I'd +1
>>> it.
>>> > >
>>> > > Cheers
>>> > > Joe
>>> > >
>>> > > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
>>> >> > .com>
>>> > > wrote:
>>> > >
>>> > >> Hi everyone,
>>> > >>
>>> > >> Two weeks have passed since this RFC was put to discussion here.
>>> > >>
>>> > >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
>>> > >>
>>> > >> Voting starts today, 2016-11-06, and will close after two weeks on
>>> the
>>> > >> Sunday 2016-11-20 at midnight.
>>> > >>
>>> > >> The RFC and voting widget can be found here:
>>> > >> https://wiki.php.net/rfc/object-typehint
>>>
>>
>> The vote appears to be closed right now, did I miss an announcement?
>>
>>
>>>
>>> > >>
>>> > >> It's a normal 2/3 majority required vote.
>>> > >>
>>> > >> Thanks!
>>> > >> --
>>> > >> regards / pozdrawiam,
>>> > >> --
>>> > >> Michał Brzuchalski
>>> > >> about.me/brzuchal
>>> > >> brzuchalski.com
>>> > >>
>>> > >
>>> >
>>> >
>>> > --
>>> > PHP Internals - PHP Runtime Development Mailing List
>>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>> >
>>> >
>>>
>>
>>
>

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Joe Watkins]

Morning Peter,

> I'll put RFC: On hold, then apply patch, draft some info in RFC and then
set up new voting.

Just a few messages up from here ...

Would you prefer a new thread to make that announcement (I think it may be
better) ?

Cheers
Joe

On Thu, Nov 10, 2016 at 9:52 AM, Peter Cowburn 
wrote:

>
>
> On 10 November 2016 at 09:11, Niklas Keller  wrote:
>
>> 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
>>
>> > On 09.11.2016 at 17:28, Joe Watkins wrote:
>> >
>> > > I want to explain why I voted no on this:
>> > >
>> > > I think it's significantly less useful without variance, variance
>> is
>> > > something that is usually difficult to achieve in PHP, but not for
>> this
>> > > feature in particular.
>> >
>> > Can you please elaborate what you mean with variance?  I see some
>> > practical use cases for covariance of a method with return type object,
>> > but I don't see how contravariance could be achieved for parameters of
>> > type object.
>> >
>> > If your suggestion is only about invariance of object return types, I'm
>> > not sure if this very special case would make sense (for consistency
>> > reasons).
>> >
>>
>> We already have it for iterable -> array. We would have it for all other
>> types if there wouldn't be an implementation issue.
>>
>> Regards, Niklas
>>
>> Cheers,
>> > Christoph
>> >
>> > > I absolutely want it, but I want it to be properly useful.
>> > >
>> > > If the RFC were halted and patched to include variance, I'd +1 it.
>> > >
>> > > Cheers
>> > > Joe
>> > >
>> > > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski
>> > > .com>
>> > > wrote:
>> > >
>> > >> Hi everyone,
>> > >>
>> > >> Two weeks have passed since this RFC was put to discussion here.
>> > >>
>> > >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
>> > >>
>> > >> Voting starts today, 2016-11-06, and will close after two weeks on
>> the
>> > >> Sunday 2016-11-20 at midnight.
>> > >>
>> > >> The RFC and voting widget can be found here:
>> > >> https://wiki.php.net/rfc/object-typehint
>>
>
> The vote appears to be closed right now, did I miss an announcement?
>
>
>>
>> > >>
>> > >> It's a normal 2/3 majority required vote.
>> > >>
>> > >> Thanks!
>> > >> --
>> > >> regards / pozdrawiam,
>> > >> --
>> > >> Michał Brzuchalski
>> > >> about.me/brzuchal
>> > >> brzuchalski.com
>> > >>
>> > >
>> >
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>
>

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Peter Cowburn]

On 10 November 2016 at 09:11, Niklas Keller  wrote:

> 2016-11-09 21:53 GMT+01:00 Christoph M. Becker :
>
> > On 09.11.2016 at 17:28, Joe Watkins wrote:
> >
> > > I want to explain why I voted no on this:
> > >
> > > I think it's significantly less useful without variance, variance
> is
> > > something that is usually difficult to achieve in PHP, but not for this
> > > feature in particular.
> >
> > Can you please elaborate what you mean with variance?  I see some
> > practical use cases for covariance of a method with return type object,
> > but I don't see how contravariance could be achieved for parameters of
> > type object.
> >
> > If your suggestion is only about invariance of object return types, I'm
> > not sure if this very special case would make sense (for consistency
> > reasons).
> >
>
> We already have it for iterable -> array. We would have it for all other
> types if there wouldn't be an implementation issue.
>
> Regards, Niklas
>
> Cheers,
> > Christoph
> >
> > > I absolutely want it, but I want it to be properly useful.
> > >
> > > If the RFC were halted and patched to include variance, I'd +1 it.
> > >
> > > Cheers
> > > Joe
> > >
> > > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski  > .com>
> > > wrote:
> > >
> > >> Hi everyone,
> > >>
> > >> Two weeks have passed since this RFC was put to discussion here.
> > >>
> > >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
> > >>
> > >> Voting starts today, 2016-11-06, and will close after two weeks on the
> > >> Sunday 2016-11-20 at midnight.
> > >>
> > >> The RFC and voting widget can be found here:
> > >> https://wiki.php.net/rfc/object-typehint
>

The vote appears to be closed right now, did I miss an announcement?


>
> > >>
> > >> It's a normal 2/3 majority required vote.
> > >>
> > >> Thanks!
> > >> --
> > >> regards / pozdrawiam,
> > >> --
> > >> Michał Brzuchalski
> > >> about.me/brzuchal
> > >> brzuchalski.com
> > >>
> > >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Niklas Keller]

2016-11-09 21:53 GMT+01:00 Christoph M. Becker :

> On 09.11.2016 at 17:28, Joe Watkins wrote:
>
> > I want to explain why I voted no on this:
> >
> > I think it's significantly less useful without variance, variance is
> > something that is usually difficult to achieve in PHP, but not for this
> > feature in particular.
>
> Can you please elaborate what you mean with variance?  I see some
> practical use cases for covariance of a method with return type object,
> but I don't see how contravariance could be achieved for parameters of
> type object.
>
> If your suggestion is only about invariance of object return types, I'm
> not sure if this very special case would make sense (for consistency
> reasons).
>

We already have it for iterable -> array. We would have it for all other
types if there wouldn't be an implementation issue.

Regards, Niklas

Cheers,
> Christoph
>
> > I absolutely want it, but I want it to be properly useful.
> >
> > If the RFC were halted and patched to include variance, I'd +1 it.
> >
> > Cheers
> > Joe
> >
> > On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski  .com>
> > wrote:
> >
> >> Hi everyone,
> >>
> >> Two weeks have passed since this RFC was put to discussion here.
> >>
> >> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
> >>
> >> Voting starts today, 2016-11-06, and will close after two weeks on the
> >> Sunday 2016-11-20 at midnight.
> >>
> >> The RFC and voting widget can be found here:
> >> https://wiki.php.net/rfc/object-typehint
> >>
> >> It's a normal 2/3 majority required vote.
> >>
> >> Thanks!
> >> --
> >> regards / pozdrawiam,
> >> --
> >> Michał Brzuchalski
> >> about.me/brzuchal
> >> brzuchalski.com
> >>
> >
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Christoph M. Becker]

On 09.11.2016 at 17:28, Joe Watkins wrote:

> I want to explain why I voted no on this:
> 
> I think it's significantly less useful without variance, variance is
> something that is usually difficult to achieve in PHP, but not for this
> feature in particular.

Can you please elaborate what you mean with variance?  I see some
practical use cases for covariance of a method with return type object,
but I don't see how contravariance could be achieved for parameters of
type object.

If your suggestion is only about invariance of object return types, I'm
not sure if this very special case would make sense (for consistency
reasons).

Cheers,
Christoph

> I absolutely want it, but I want it to be properly useful.
> 
> If the RFC were halted and patched to include variance, I'd +1 it.
> 
> Cheers
> Joe
> 
> On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski 
> wrote:
> 
>> Hi everyone,
>>
>> Two weeks have passed since this RFC was put to discussion here.
>>
>> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
>>
>> Voting starts today, 2016-11-06, and will close after two weeks on the
>> Sunday 2016-11-20 at midnight.
>>
>> The RFC and voting widget can be found here:
>> https://wiki.php.net/rfc/object-typehint
>>
>> It's a normal 2/3 majority required vote.
>>
>> Thanks!
>> --
>> regards / pozdrawiam,
>> --
>> Michał Brzuchalski
>> about.me/brzuchal
>> brzuchalski.com
>>
> 


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Christoph M. Becker]

On 09.11.2016 at 21:53, Christoph M. Becker wrote:

> On 09.11.2016 at 17:28, Joe Watkins wrote:
> 
>> I want to explain why I voted no on this:
>>
>> I think it's significantly less useful without variance, variance is
>> something that is usually difficult to achieve in PHP, but not for this
>> feature in particular.
> 
> Can you please elaborate what you mean with variance?  I see some
> practical use cases for covariance of a method with return type object,
> but I don't see how contravariance could be achieved for parameters of
> type object.
> 
> If your suggestion is only about invariance of object return types, I'm
   ^^ should be covariance
> not sure if this very special case would make sense (for consistency
> reasons).
> 
> Cheers,
> Christoph
> 
>> I absolutely want it, but I want it to be properly useful.
>>
>> If the RFC were halted and patched to include variance, I'd +1 it.
>>
>> Cheers
>> Joe
>>
>> On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> Two weeks have passed since this RFC was put to discussion here.
>>>
>>> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
>>>
>>> Voting starts today, 2016-11-06, and will close after two weeks on the
>>> Sunday 2016-11-20 at midnight.
>>>
>>> The RFC and voting widget can be found here:
>>> https://wiki.php.net/rfc/object-typehint
>>>
>>> It's a normal 2/3 majority required vote.
>>>
>>> Thanks!
>>> --
>>> regards / pozdrawiam,
>>> --
>>> Michał Brzuchalski
>>> about.me/brzuchal
>>> brzuchalski.com
>>>
>>
> 


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Michał Brzuchalski]

Hi Joe,

If that's gonna improve feature I'll be happy to patch and then restart
voting.

I hope it's gonna satisfy more voters :)

I'll put RFC: On hold, then apply patch, draft some info in RFC and then
set up new voting.


Cheers,

2016-11-09 17:28 GMT+01:00 Joe Watkins :

> Morning Internals,
>
> I want to explain why I voted no on this:
>
> I think it's significantly less useful without variance, variance is
> something that is usually difficult to achieve in PHP, but not for this
> feature in particular.
>
> I absolutely want it, but I want it to be properly useful.
>
> If the RFC were halted and patched to include variance, I'd +1 it.
>
> Cheers
> Joe
>
> On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski  > wrote:
>
>> Hi everyone,
>>
>> Two weeks have passed since this RFC was put to discussion here.
>>
>> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
>>
>> Voting starts today, 2016-11-06, and will close after two weeks on the
>> Sunday 2016-11-20 at midnight.
>>
>> The RFC and voting widget can be found here:
>> https://wiki.php.net/rfc/object-typehint
>>
>> It's a normal 2/3 majority required vote.
>>
>> Thanks!
>> --
>> regards / pozdrawiam,
>> --
>> Michał Brzuchalski
>> about.me/brzuchal
>> brzuchalski.com
>>
>
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC][VOTE] Object typehint

[Joe Watkins]

Morning Internals,

I want to explain why I voted no on this:

I think it's significantly less useful without variance, variance is
something that is usually difficult to achieve in PHP, but not for this
feature in particular.

I absolutely want it, but I want it to be properly useful.

If the RFC were halted and patched to include variance, I'd +1 it.

Cheers
Joe

On Sun, Nov 6, 2016 at 5:28 PM, Michał Brzuchalski 
wrote:

> Hi everyone,
>
> Two weeks have passed since this RFC was put to discussion here.
>
> Therefore, I'm going to put it to a vote for inclusion in PHP 7.2.
>
> Voting starts today, 2016-11-06, and will close after two weeks on the
> Sunday 2016-11-20 at midnight.
>
> The RFC and voting widget can be found here:
> https://wiki.php.net/rfc/object-typehint
>
> It's a normal 2/3 majority required vote.
>
> Thanks!
> --
> regards / pozdrawiam,
> --
> Michał Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>