Re: [RFC] [PRE-VOTE] Union types

From: Date: Sat, 04 Jun 2016 13:48:03 +0000
Subject: Re: [RFC] [PRE-VOTE] Union types
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20  Groups: php.internals 
Request: Send a blank email to internals+get-93764@lists.php.net to get a copy of this message
> > Massive is a nice hyperbole here... > Sure, you can check it manually… but why not just always check it manually > then? > You then loose possibilities to reflect on it, have static analysis rely > on code only [currently you always have to check docblocks when it's not > declared; definitely not an option for e.g. Optimizer], and a single > signature is generally easier to parse for a human. > Talking about reflection, I'm not happy with the currently proposed solution. > ReflectionType::__toString() will now provide a full union type as string; e.g. “int | float | NumberObject”. That requires libraries like Auryn to manually parse that string now. It's no longer possible to directly use __toString to get the class name. Isn't there a better solution? What about ReflectionType::isBuiltin()? What will it return? Just false? True if only built in types are used? I think allowsNull can be handled as is. See https://3v4l.org/int0g#v700. > Also, I don't believe it's the languages task to put arbitrary limitations > on this. If a library does this, that's the libraries problem. But a > language should not do that and try to support full typing. We've decided > to make PHP (opt-in) typed on function boundaries (and eventually soon on > property storage boundaries), so we should also finish what we committed to > instead of putting something half-arsed forward. > > For Aerys\Host it could also be solved with an interface that just doesn't > have any methods. With the disadvantage of callable not being in the same > signature anymore. > > > As you say, disadvantage of callable. Also, it requires you to inverse > responsibilities. You'd have to specify a common super-interface on every > single fundamentally unrelated interface (which are only indirectly related > by the fact that they receive common handling in a single place). That's a > clear anti-pattern. > Additionally, this is only possible if you are actually in control on > these classes and can change them. If you pull them from a library, no > chance. > > Bob >

« previous php.internals (#93764) next »