Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96882
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.49 cause and error)
MIME-Version: 1.0
In-Reply-To: <CABdc3Wpe9_S=0wi5tMGw8LpyqKPAwWVPXjM38UsSxz5W4oyKaw@mail.gmail.com>
References: <CABdc3Wpx37dV28Z55kejhzFMpxADp-aN-oO8KWSriV_L59VAiw@mail.gmail.com>
 <CAL=_i_kTWEbfaANN99WFAnxf3RcvtpFozyqNn=ZZgVGQwwUa0Q@mail.gmail.com>
 <0c171a20-c72d-4157-1117-6628a52dd1f0@gmx.de> <CANUQDCgHMu9X=mWZtAumCBOdGKYaenmf2Hz1rAspZDGnfCTuuA@mail.gmail.com>
 <CAFMT4Noa2=4kHXuANx0Gq7p7dGG4BjUf7qgFwJvk6+bp_kx55Q@mail.gmail.com>
 <CAL=_i_=8fSytaskkWS6qK9KFU-5FneGXyTm6CE_T+u8RRmBAGA@mail.gmail.com>
 <CAFMT4Npz8qncXAFBPitU87=DOC-3v+DQcGxdzoHN3oQUmbyK8w@mail.gmail.com>
 <CAL=_i_m=fyouC20wTn0Lx8GYLrfwtmHg-bfTx0ais4dEN0xNqg@mail.gmail.com>
 <CABdc3Wp2Z_BW9hW1mniqR2jpCGVqH4fgGqyrKuHBjeN8rrTHoQ@mail.gmail.com> <CABdc3Wpe9_S=0wi5tMGw8LpyqKPAwWVPXjM38UsSxz5W4oyKaw@mail.gmail.com>
Date: Mon, 14 Nov 2016 09:20:16 +0000
Message-ID: <CAL=_i_=H47J4Na1Y5vGKTSkabjVV2gP5aq_sL35BnVvQ=bC5Ow@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>
Cc: Levi Morrison <levim@php.net>, Niklas Keller <me@kelunik.com>, 
	"Christoph M. Becker" <cmbecker69@gmx.de>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11444da814efc305413f59d6
Subject: Re: [PHP-DEV] [RFC][VOTE] Object typehint
From: pthreads@pthreads.org (Joe Watkins)

--001a11444da814efc305413f59d6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry people, my fault :(

On Mon, Nov 14, 2016 at 9:16 AM, Micha=C5=82 Brzuchalski <michal@brzuchalsk=
i.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=C5=82
>
> 2016-11-14 9:53 GMT+01:00 Micha=C5=82 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 behav=
es
> > covariant (more general type can be raplaced with narrowed one).
> >
> > P.S. I hope this improvement will bring more positive votes.
> >
> > regards,
> > --
> > Micha=C5=82
> >
> > 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 RF=
C
> >> has done.
> >>
> >>     If it is true that this would prohibit enums being non-objects, an=
d
> >> 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 12:20 PM, Levi Morrison <levim@php.net> wrote:
> >>
> >>> 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.d=
e
> >:
> >>> >> >
> >>> >> >> On 09.11.2016 at 17:28, Joe Watkins wrote:
> >>> >> >>
> >>> >> >> >     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 no=
t
> >>> for
> >>> >> >> > this
> >>> >> >> > feature in particular.
> >>> >> >>
> >>> >> >> Can you please elaborate what you mean with variance?  I see so=
me
> >>> >> >> 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 a=
ll
> >>> 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=C5=82 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 PH=
P
> >>> 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=C5=82 Brzuchalski
> >>> >> >> >> about.me/brzuchal
> >>> >> >> >> brzuchalski.com
> >>> >> >> >>
> >>> >> >> >
> >>> >> >>
> >>> >> >>
> >>> >> >> --
> >>> >> >> PHP Internals - PHP Runtime Development Mailing List
> >>> >> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>> >> >>
> >>> >> >>
> >>> >>
> >>> >> In a return type context `iterable` can be changed to `Traversable=
`
> or
> >>> >> `array`; it cannot be changed to `Collection` as we cannot guarant=
ee
> >>> >> 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, enum=
s
> >>> >> are an often requested feature and they may not be objects. Thus w=
e
> >>> >> 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=C5=82 Brzuchalski
> > about.me/brzuchal
> > brzuchalski.com
> >
>
>
>
> --
> regards / pozdrawiam,
> --
> Micha=C5=82 Brzuchalski
> about.me/brzuchal
> brzuchalski.com
>

--001a11444da814efc305413f59d6--