# [RFC] [VOTE] Object typehint RFC - Thread: https://externals.io/message/99068 - Original archive: https://news-web.php.net/php.internals/99068 - Started by michal@brzuchalski.com on 2017-05-17T10:34:28+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #99068 — michal@brzuchalski.com — 2017-05-17T10:34:28+00:00 URL: https://externals.io/message/99068#99068 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 --- ## #99075 — Levi Morrison — 2017-05-17T14:47:15+00:00 URL: https://externals.io/message/99068#99075 · In reply to: #99068 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. --- ## #99076 — Andrey Andreev — 2017-05-17T14:52:04+00:00 URL: https://externals.io/message/99068#99076 · In reply to: #99075 Hi, > > 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. --- ## #99079 — Sebastian Bergmann — 2017-05-17T15:33:28+00:00 URL: https://externals.io/message/99068#99079 · In reply to: #99075 > 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 :-) --- ## #99080 — michal@brzuchalski.com — 2017-05-17T16:26:03+00:00 URL: https://externals.io/message/99068#99080 · In reply to: #99075 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 < > michal@brzuchalski.com> wrote: > > > […] > > 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 --- ## #99081 — Levi Morrison — 2017-05-17T16:43:49+00:00 URL: https://externals.io/message/99068#99081 · In reply to: #99080 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 : > > > […] > 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. --- ## #99082 — Dan Ackroyd — 2017-05-17T17:12:36+00:00 URL: https://externals.io/message/99068#99082 · In reply to: #99080 > 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 --- ## #99083 — michal@brzuchalski.com — 2017-05-17T17:12:59+00:00 URL: https://externals.io/message/99068#99083 · In reply to: #99081 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 --- ## #99084 — michal@brzuchalski.com — 2017-05-17T17:14:20+00:00 URL: https://externals.io/message/99068#99084 · In reply to: #99082 2017-05-17 19:12 GMT+02:00 Dan Ackroyd : > > […] > > Who do you mean 'we', kemosabe? > My apologies. I was a little hurry. > > > […] > > 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 --- ## #99336 — Nikita Popov — 2017-06-03T10:54:57+00:00 URL: https://externals.io/message/99068#99336 · In reply to: #99068 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 --- ## #99498 — michal@brzuchalski.com — 2017-06-12T19:00:03+00:00 URL: https://externals.io/message/99068#99498 · In reply to: #99336 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 < > michal@brzuchalski.com> wrote: > > > […] > > 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