Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99080
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFMT4NqTKJ0fjQbJr1h7bQBXsO2gzpAOM=k_9wrgaCjQA4tgmA@mail.gmail.com>
References: <CABdc3WrBVOUDuohP1RrFhQTv==otTGHuKuMe-JVD2DU2EaHDRQ@mail.gmail.com>
 <CAFMT4NqTKJ0fjQbJr1h7bQBXsO2gzpAOM=k_9wrgaCjQA4tgmA@mail.gmail.com>
Date: Wed, 17 May 2017 18:26:03 +0200
Message-ID: <CABdc3Wqf5GsrbNV4ijyhmn61PFL7m_MUy1LUzwCXO3mPBhuokg@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c05e9589630d3054fbabe54"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--94eb2c05e9589630d3054fbabe54
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank your Levi for your explanation.

2017-05-17 16:47 GMT+02:00 Levi Morrison <levim@php.net>:

>
>
> On Wed, May 17, 2017 at 4:34 AM, Micha=C5=82 Brzuchalski <
> michal@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 a=
re
>> 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 varianc=
e
>> behaviour on the object type which also require 2/3 majority.
>>
>> Thanks!
>> --
>> regards / pozdrawiam,
>> --
>> Micha=C5=82 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 ar=
e
> not objects. The reason is that the way this is implemented it just assum=
es
> 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 pa=
st.
>



--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--94eb2c05e9589630d3054fbabe54--