[RFC][VOTE] Object typehint

8 years ago by michal@brzuchalski.com — view source

unread

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

8 years ago by Joe Watkins — view source

unread

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

8 years ago by michal@brzuchalski.com — view source

unread

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

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

--
regards / pozdrawiam,

Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

8 years ago by Christoph M. Becker — view source

unread

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

8 years ago by Christoph M. Becker — view source

unread

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

8 years ago by Niklas Keller — view source

unread

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

8 years ago by Peter Cowburn — view source

unread

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

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

8 years ago by Joe Watkins — view source

unread

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 petercowburn@gmail.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
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

8 years ago by Peter Cowburn — view source

unread

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 petercowburn@gmail.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
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

8 years ago by Levi Morrison — view source

unread

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.

8 years ago by Joe Watkins — view source

unread

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

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.

8 years ago by Levi Morrison — view source

unread

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
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.

8 years ago by Joe Watkins — view source

unread

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
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.

8 years ago by michal@brzuchalski.com — view source

unread

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

8 years ago by michal@brzuchalski.com — view source

unread

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

8 years ago by Joe Watkins — view source

unread

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

8 years ago by Josh Di Fabio — view source

unread

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.

8 years ago by michal@brzuchalski.com — view source

unread

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

[RFC][VOTE] Object typehint

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

-- regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

Thanks!

regards / pozdrawiam,

regards,

Thanks!

regards / pozdrawiam,

-- regards / pozdrawiam,

regards,

Thanks!

regards / pozdrawiam,

-- regards / pozdrawiam,

-- regards / pozdrawiam,

regards,

Thanks!

regards / pozdrawiam,

-- regards / pozdrawiam,

-- regards / pozdrawiam,

regards,

Thanks!

regards / pozdrawiam,

-- regards / pozdrawiam,

regards,

Thanks!

regards / pozdrawiam,

-- regards / pozdrawiam,

-- regards / pozdrawiam,

--
regards / pozdrawiam,

--
regards / pozdrawiam,

--
regards / pozdrawiam,

--
regards / pozdrawiam,

--
regards / pozdrawiam,

--
regards / pozdrawiam,

--
regards / pozdrawiam,

--
regards / pozdrawiam,

--
regards / pozdrawiam,