On Wed, May 17, 2017 at 10:26 AM, Michał Brzuchalski <mic...@brzuchalski.com > wrote:
> Thank your Levi for your explanation. > > 2017-05-17 16:47 GMT+02:00 Levi Morrison <le...@php.net>: > >> >> >> 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 <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.
