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
