Levi,
You are assuming it would *need* to be removed :)
Future RFC's must deal with the engine as they find it, as this RFC has
done.
If it is true that this would prohibit enums being non-objects, and 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 <le...@php.net> wrote:
> On Thu, Nov 10, 2016 at 5:18 AM, Joe Watkins <pthre...@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 <le...@php.net> wrote:
> >>
> >> On Thu, Nov 10, 2016 at 2:11 AM, Niklas Keller <m...@kelunik.com> wrote:
> >> > 2016-11-09 21:53 GMT+01:00 Christoph M. Becker <cmbecke...@gmx.de>:
> >> >
> >> >> 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 not for
> >> >> > this
> >> >> > feature in particular.
> >> >>
> >> >> Can you please elaborate what you mean with variance? I see some
> >> >> 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 all
> 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ł 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 PHP 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ł 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 guarantee
> >> 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, enums
> >> are an often requested feature and they may not be objects. Thus we
> >> 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.
>
