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

Reply via email to