[RFC][VOTE] Object typehint View as Markdown

Sorry people, my fault :(

On Mon, Nov 14, 2016 at 9:16 AM, Michał Brzuchalski michal@brzuchalski.com
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 michal@brzuchalski.com:

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 pthreads@pthreads.org:

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 5:18 AM, Joe Watkins pthreads@pthreads.org
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 levim@php.net
wrote:

On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller me@kelunik.com
wrote:

2016-11-09 21:53 GMT+01:00 Christoph M. Becker <cmbecker69@gmx.de
:

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
<michal@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

--

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.

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

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 joshdifabio@gmail.com:

On Mon, Nov 14, 2016 at 8:54 AM Michał Brzuchalski michal@brzuchalski.com
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 pthreads@pthreads.org:

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 5:18 AM, Joe Watkins pthreads@pthreads.org
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 levim@php.net
wrote:

On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller me@kelunik.com
wrote:

2016-11-09 21:53 GMT+01:00 Christoph M. Becker <cmbecker69@gmx.de
:

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
<michal@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

--

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.

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

P.S. Apologies for the non-plaintext email.

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com