On 3/9/2017 12:47 PM, Andrey Andreev wrote: > Hi, Hey :)
On 3/9/2017 12:47 PM, Andrey Andreev wrote: > On Thu, Mar 9, 2017 at 1:49 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: >> Stringable seems very explicit and strict to me, since it is opt-in. >> Currently there is no way to have the ergonomics of coercion if strict >> mode is active for a file. This could be a very explicit way to enable >> it for portions. >> > > I don't understand what you're trying to say here, or rather what you > mean by "stringable" at this point ... Is it a compound type for > string and __toString() objects only, or not? Your last comments > suggest that it isn't. All scalars, null, and objects with a __toString are stringable. I argued at first that we should only bridge string and objects with a __toString but later came to the conclusion that it does not add value. I understand that this might be confusing, since there are right now many messages in this thread. 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. 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. As you can see, it does not matter if the stringable pseudo-type accepts more than just string and objects with a __toString method. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
