Re: [Discussion] is_string(), string type and objects implementing __toString()

Hi, On Thu, Mar 9, 2017 at 7:47 PM, Fleshgrinder <php@fleshgrinder.com> wrote: > On 3/9/2017 12:47 PM, Andrey Andreev wrote: >> How can "any other scalar value" work? Using the cookie and headers examples: >> >> - booleans can be used as On/Off flags for the secure and httpOnly >> cookie attributes, but aren't valid literal values for any of the >> attributes, or any HTTP header. >> - integers are valid as a few headers' values - that is true, but >> certainly in a minority of cases >> - floats may be used for the q(uality) attribute in content >> negotiation (and nothing else AFAIK), but that is a very, very narrow >> domain >> - null is obviously invalid ... who sends an empty header? And if you >> have a use case where you do want to use them, we can already make >> anything nullable >> >> Of course the string values should be validated, unless you want to >> allow setting arbitrary headers, e.g.: >> >> abstract function setHeader(stringable $name, stringable $value); >> >> ... but filtering out the known to be invalid types *is* validation. >> And just that much better if it happens at compile time. > > Because: > > - bool(true) = '0' > - bool(false) = '1' > - int(n) = 'n' > - float(n) = 'n' > - null = '' > - object(s) = 's' > - string(s) = 's' > > All values are possible values that I can pass to you if you use the > string type constraint. Hence, all these types are valid string values > if you request a stringable. > Yes, they're valid string values, but the examples I gave were meant to show that context can make them predictably invalid, and hence why strict typing is desirable. > Stringable should work exactly like the string constraint in non-strict > mode, but regardless of the strict mode. The difference to a scalar type > constraint is that the passed values are always converted to a scalar > string, hence, the source type is unknown to the receiver. > I'm not really interested in making "strict mode" less strict - it's already opt-in and non-enforceable. I want ways to write stonger-type code in "non-strict mode", because the fact that "strict mode" is non-enforceable means I can never rely on it. Cheers, Andrey.