Internals,
As alluded to last week I have another RFC for improving the type
system: intersection types.
It allows parameters to define multiple type constraints that must be
satisfied. Common combinations of our built-in types include
ArrayAccess & Traversable & Countable and Countable & Iterator.
Some people have suggest I merge this and union types into one RFC.
For now I'll just proceed with them separately to gain feedback.
Internals,
As alluded to last week I have another RFC for improving the type
system: intersection types.It allows parameters to define multiple type constraints that must be
satisfied. Common combinations of our built-in types include
ArrayAccess & Traversable & CountableandCountable & Iterator.Some people have suggest I merge this and union types into one RFC.
For now I'll just proceed with them separately to gain feedback.--
To me, it seems that intersection types are more useful than union
types (other than the obvious null|Foo and array|Traversable cases) as
they'd allow us to write smaller interfaces and better follow ISP in
userland, with interfaces becoming much more convenient for
documenting the requirements of a parameter.
At present we tend to have incomplete implementations of interfaces
(e.g. throw OperationNotSupportedException). Union types would allow
us to create more, smaller interfaces and avoid situations where the
type of a parameter doesn't accurately reflect the method's true
requirements, or where concretions are incomplete implementations of
an interface.
Thanks for your efforts, Levi, I'm excited about this one!
Nice!
I've read the RFC and there's only one missing thing that is either
undocumented or missed during patch creation: instanceof.
I'd be amazing if we could do: $foo instanceof Foo & Bar
Cheers,
On Thu, Apr 28, 2016 at 5:00 AM, Josh Di Fabio joshdifabio@gmail.com
wrote:
Internals,
As alluded to last week I have another RFC for improving the type
system: intersection types.It allows parameters to define multiple type constraints that must be
satisfied. Common combinations of our built-in types include
ArrayAccess & Traversable & CountableandCountable & Iterator.Some people have suggest I merge this and union types into one RFC.
For now I'll just proceed with them separately to gain feedback.--
To me, it seems that intersection types are more useful than union
types (other than the obvious null|Foo and array|Traversable cases) as
they'd allow us to write smaller interfaces and better follow ISP in
userland, with interfaces becoming much more convenient for
documenting the requirements of a parameter.At present we tend to have incomplete implementations of interfaces
(e.g. throw OperationNotSupportedException). Union types would allow
us to create more, smaller interfaces and avoid situations where the
type of a parameter doesn't accurately reflect the method's true
requirements, or where concretions are incomplete implementations of
an interface.Thanks for your efforts, Levi, I'm excited about this one!
--
--
Guilherme Blanco
Lead Architect at E-Block
Am 28.4.2016 um 17:11 schrieb guilhermeblanco@gmail.com:
Nice!
I've read the RFC and there's only one missing thing that is either
undocumented or missed during patch creation: instanceof.
I'd be amazing if we could do: $foo instanceof Foo & BarCheers,
On Thu, Apr 28, 2016 at 5:00 AM, Josh Di Fabio joshdifabio@gmail.com
wrote:Internals,
As alluded to last week I have another RFC for improving the type
system: intersection types.It allows parameters to define multiple type constraints that must be
satisfied. Common combinations of our built-in types include
ArrayAccess & Traversable & CountableandCountable & Iterator.Some people have suggest I merge this and union types into one RFC.
For now I'll just proceed with them separately to gain feedback.--
To me, it seems that intersection types are more useful than union
types (other than the obvious null|Foo and array|Traversable cases) as
they'd allow us to write smaller interfaces and better follow ISP in
userland, with interfaces becoming much more convenient for
documenting the requirements of a parameter.At present we tend to have incomplete implementations of interfaces
(e.g. throw OperationNotSupportedException). Union types would allow
us to create more, smaller interfaces and avoid situations where the
type of a parameter doesn't accurately reflect the method's true
requirements, or where concretions are incomplete implementations of
an interface.Thanks for your efforts, Levi, I'm excited about this one!
--
Guilherme Blanco
Lead Architect at E-Block
Who’s top-posting here? ;-)
Regarding your suggestion, $foo instanceof Foo & Bar is conflicting with bitwise and here. Anyway, you already can $foo instanceof Foo && $foo instanceof Bar. Which is IMO just as easy, not conflicting and more flexible.
Also, instanceof would not (at least not currently) work with scalar types, array or callable. (i.e. $foo instanceof string doesn’t work). And thus $foo instanceof Foo & callable doesn’t either. Which is quite a difference to intersection/union types.
Bob
Bob Weinand wrote on 28/04/2016 16:49:
Regarding your suggestion, $foo instanceof Foo & Bar is conflicting with bitwise and here. Anyway, you already can $foo instanceof Foo && $foo instanceof Bar. Which is IMO just as easy, not conflicting and more flexible.
It's a shame that that's so verbose. It would be amazing to have
something like Perl6's "Junctions":
https://perlgeek.de/blog-en.cgi/perl-5-to-6/08-junctions.html
$foo instanceof any(Foo, Bar)
Well, I can dream... ;)