Nope, it pretty much made perfect sense to me the first time. But you may
get your wish in it going in with the proposal anyway as I don't think this
RFC is going to make it in time for the 7.1 window.
My crack at implementing it went bust when I realised I was adding too many
execute globals.
Speaking of implementation though. Does anyone have a fairly good idea on
how to do it? I got the parser ambiguity out of the way, but my attempts
at building the complete feature were mostly experimental. So I'd like to
get an idea of how likely it is someone else will be able to take over.
On 21 Apr 2016 4:25 p.m., "guilhermebla...@gmail.com" <
guilhermebla...@gmail.com> wrote:
> I see that some of you are confusing union types with intersecting types
> here. The idea is not an OR, but an AND.
> I'll repeat the same example again to try to exemplify what I mentioned:
>
> class AA {}
> interface B {}
> interface C {}
> class BB extends AA implements B {}
> class CC extends AA implements B, C {}
>
> class Foo<T instanceof AA & B & C> {}
> class Bar<T instanceof AA | B | C> {}
>
> Class Foo means an intersecting type, where only class CC is applicable
> there. Class Bar means a union type, whee both AA, BB and CC are
> applicable.
>
> I understand others mentioned we could create a new interface that wraps
> the other two interfaces, but that still doesn't solve the problem where I
> want to extend a class AND also implement a specific interface.
> Surely this can be a subsequent RFC, but I see that as a deficiency of the
> currently proposed one and consider it incomplete. What happens if the
> initial one get approved but it is too late to propose the subsequent one?
> Then PHP 7.1 would be released with a partial implementation and not fully
> featured as it should.
>
>
> Regards,
>
>
> On Wed, Apr 20, 2016 at 11:18 PM, Jesse Schalken <m...@jesseschalken.com>
> wrote:
>
> > On Thu, Apr 21, 2016 at 8:56 AM, Rowan Collins <rowan.coll...@gmail.com>
> > wrote:
> > >
> > > I'm not quite sure what bounds would mean for anything other than
> classes
> > > or interfaces. A generic type that specified that its type parameter
> must
> > > be an int seems to me to be a non-generic type, because nothing other
> > than
> > > an int "is int". How is "class Foo<T is int> { public function
> > > __construct(T $arg) { ... } }" different from just saying "class Foo {
> > > public function __construct(int $arg) { ... } }"? (Unless there were
> some
> > > kind of overloading, such that you could also have Foo<T is float>, but
> > > please let's not go there...)
> > >
> >
> > Sticking with your example for a moment, if the type parameter is an
> "int",
> > then the only type that can *currently* be expressed in the type language
> > that is a subtype of "int" is "int", so it's not very useful *right now*.
> > However, a possible introduction of integer literal types would change
> > that, especially in combination with unions. This would enable you to
> > express the type "1|2|3", i.e. only one of those three integers. This
> would
> > be useful to typecheck enums, which are typically an "int" or "string"
> > which only accepts a finite set of values. As such, the type parameter "T
> > is int" could be filled with "int" or "1" or "0|1|2". (Imagine a class
> > "Bar<T is int>" and various subclasses which each must select a single
> > integer as kind of tag, "Foo extends Bar<1>", "Baz extends Bar<2>" etc. I
> > do this in TypeScript with string literal types all the time.)
> >
> > Beside from that, the introduction of any one of union types,
> intersection
> > types, generic array types or callable types would mean the type
> constraint
> > for a generic type can usefully be something besides a single
> > class/interface. For example, if "<T is array|Travarsable>" were written
> > "<T instanceof array|Traversable>" I would expect to be able to do "$t
> > instanceof array|Traversable", but I wouldn't be able to unless
> > "instanceof" is intended to and is extended to support arbitrary types.
> >
> > Note that generic arrays are out of scope of the current RFC anyway, so
> > > it's possible that "$t instanceof array<Bar>" could be added at the
> same
> > > time as "Foo<T instanceof array<Bar>>", presumably with the meaning
> that
> > > "array<SubClassOfBar>" would be considered to pass the check.
> > >
> > > Regards,
> > >
> > > --
> > > Rowan Collins
> > > [IMSoP]
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
>
>
>
> --
> Guilherme Blanco
> Lead Architect at E-Block
>
