Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99081
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.178 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CABdc3Wqf5GsrbNV4ijyhmn61PFL7m_MUy1LUzwCXO3mPBhuokg@mail.gmail.com>
References: <CABdc3WrBVOUDuohP1RrFhQTv==otTGHuKuMe-JVD2DU2EaHDRQ@mail.gmail.com>
 <CAFMT4NqTKJ0fjQbJr1h7bQBXsO2gzpAOM=k_9wrgaCjQA4tgmA@mail.gmail.com> <CABdc3Wqf5GsrbNV4ijyhmn61PFL7m_MUy1LUzwCXO3mPBhuokg@mail.gmail.com>
Date: Wed, 17 May 2017 10:43:49 -0600
Message-ID: <CAFMT4NoE7=+32rf2yR9kSh4nbRJ_Rsm3=U2Y8XYhxYVOwSje4A@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11427a6028dbcb054fbafe0a"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC
From: levim@php.net (Levi Morrison)

--001a11427a6028dbcb054fbafe0a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 17, 2017 at 10:26 AM, Micha=C5=82 Brzuchalski <michal@brzuchals=
ki.com
> wrote:

> 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
>>> 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 th=
e
>>> patch which require 2/3 majority.
>>> The additional vote is also a straight Yes/No vote for accepting varian=
ce
>>> 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 reason=
s:
>>
>>   1. Object variance should be implemented when we have generalized
>> variance for all types. By special casing it now we open ourselves to th=
e
>> 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 fi=
xed
>> 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 som=
e
> 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.

--001a11427a6028dbcb054fbafe0a--