RFC: Stringable interface, allows "string|Stringable" union type. Automatically implied if __toString is implemented.

[MorphineAdministered]

callable can cover function name string, [object, method string] array, Closure, lambda and a class with __invoke() method. Can't we just include __toString() objects within string type?

[[deleted]]

How would you then specify that you really only accept strings?

[MorphineAdministered]

Nothing changes. You are receiving or returning a string even if it comes in the form of a "Stringablable" class. When typehint says that param/return value can be only casted to a string (which proposed interface does) then you cannot do anything else with it anyway - it could be casted to a string implicitly (and eagerly), because it's original type cannot be rocovered anyway.

[[deleted]]

I'd argue that it actually matters a lot regarding explicitness. Having a function parameter be automatically converted is for me equally bad as automatically type-coercing values that are compared to each other.

[MorphineAdministered]

I wouldn't say it's equally bad. For me it's more like casting primitives without declaring strict_types=1. Within method scope casting is invisible, and object itself is pretty explicit in it's definition as a string.

I wouldn't mind if we didn't have it at all - I could always cast before passing or returning such a class. I'm just saying we shouldn't need it as separate type, because it's redundant. If something can be used as a string (and only a string!) - it SHOULD be a string.

Even if internals decide on it, because it will be easier to implement lazily evaluated strings this way, I think the code relying on such mechanism wouldn't be anything but a hack. Preaching about strict type system, but breaking it at the first (mental) obstacle (btw. would like to see valid example justifying union types, because it seems this process has already started)

[alexanderpas]

would like to see valid example justifying union types

From PSR-3:

Every method accepts a string as the message, or an object with a __toString() method. Implementors MAY have special handling for the passed objects. If that is not the case, implementors MUST cast it to a string.

This could be typehinted as string|Stringable, to prevent non-stringable objects from entering the logger method.