> > 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 >