On Thu, Mar 9, 2017 at 12:42 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
>
> I still don't understand what you're using this check for that means you
> want to exclude integers. If you're passing on the value to anything that
> actually needs a string, you're doing a string cast, either explicitly or
> implicitly, so there's no difference between me passing you (string)'42',
> (int)42, or new class { function __toString() { return '42'; } }
>This goes all the way back to the heated discussion about scalar type hints ... Being explicit is the entire point, and why many people wanted strict typing. On Thu, Mar 9, 2017 at 12:43 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: > > What is the use case where every other scalar (and null) type is not > acceptable? I defended that stringable should bridge only string and > objects with __toString too first, but after thinking more about it, > there is no real world reason why one would need that. Almost all use > cases I can think about evolve around strict mode and some function that > simply does not care what it was. Hence, stringable would truly act like > the into trait in Rust. > Think of value objects. Perhaps you'd have a few methods on a value object, but mostly use it to give context to a scalar type value. For example, a Cookie object may have the cookie attributes (domain, path, etc.) as value objects, but they can easily be created from raw strings, while other types would be ambiguous. A similar effect could be desirable for HTTP headers. Also, we're talking about strings here only because we don't have __toInteger(), __toFloat(), etc. I'm not saying we should, but if we did - similar use cases would be present for other scalar types too. Even easier to imagine - a DateTime object would probably have __toInteger() returning a UNIX timestamp. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
