On 3/8/2017 7:50 PM, Nikita Popov wrote: > On Wed, Mar 8, 2017 at 7:44 PM, Andrea Faulds <a...@ajf.me> wrote: > >> Fleshgrinder wrote: >> >>> On 3/8/2017 7:36 PM, Andrea Faulds wrote: >>> >>>> Hi, >>>> >>>> Andrey Andreev wrote: >>>> >>>>> The question is rather "is this value a string?", only with the added >>>>> assumption that __toString() objects are treated as "string objects" >>>>> and thus fulfill the condition (another reason why I went for an >>>>> is_string() parameter). >>>>> >>>> >>>> This is a faulty assumption. The presence of __toString() doesn't mean >>>> the object is a string, or intended to be used like one. >>>> >>>> >>> What is it then in your book? >>> >>> >> It means the object can be converted to a string. But such a conversion >> may entail a loss of information and not be equivalent to the object >> itself. It might be a “human-readable” form, for instance. >>
Sure, and? The to-be-called function does not require that all information must be preserved, it requires that the to-be-passed argument is convertible into a string. Most probably because it wants to perform some actions on the string value, but the reasons are not of interest. As a matter of fact, any function that requests a string only asks for a string and is not aware of its contents, hence, it is also not aware of whether the to-be-passed argument might suffer from loss of information. The same is true for instance if we pass a traversable of some sort to a function that requires an iterable. We loose information! The only difference here would be that we can use feature detection to gather that information again, whereas in the Stringable implementation I envision we cannot. This is because I would convert the object to a primitive string before handing it in to the to-be-called function. This is a controlled conversion, from the sender and receiver side which is very handy in many situations. That being said, it is just sugar topping, and not having it is not a deal breaker either (since explicit casts or dedicated `toString` methods are always there). However, it would avoid certain situations of explicit casts where one might needlessly cast primitive strings, whereas with the stringable data type the runtime could take care of it. It should also be possible to generate more efficient code, since the runtime knows better what situations are possible. Something that is unclear with an explicit cast. On 3/8/2017 7:50 PM, Nikita Popov wrote: > > To give an example: Exceptions implement __toString(), which contains the > exception message, location information and backtrace. Of course, > exceptions are rather different from strings and treating an exceptions as > a string is usually incorrect. > > Nikita > For the receiver its a string and not an exception, and it does not care that it was one. Now, after thinking more about this, I actually think that it should cover other scalar types too. It might be very strict, which is nice, but at the same time this strictness does not truly add a lot of value. After all, bool, int, float, and null can always be converted to a string too. In the end the use-case is to have a type constraint in strict mode that allows more types to pass through than string only. Like a formatter (think printf). -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
