Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98440
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.83 cause and error)
Reply-To: internals@lists.php.net
References: <CAPhkiZzs=kLF-JKBjX4bVgADz+nonERWuZYiYo8cXA=GrXKU=g@mail.gmail.com>
 <8B230568-9074-4928-B9C9-F1F138054CD7@gmail.com>
 <CAPhkiZz9HwgKANZ1rZjew2r+0+SHPHJ0NFK6oQCVgmuu4viRwg@mail.gmail.com>
 <89.A9.06022.54F40C85@pb1.pair.com>
 <a4ed8231-4425-b347-6a78-35e71772bb48@fleshgrinder.com>
 <9E.4A.06022.A0150C85@pb1.pair.com>
 <CAF+90c-eE+23eBRhOqB6qtcnssGhdbx08K3jM52bHb4qXkys0Q@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <cb37fbc7-b8db-bc1d-4e73-4ac5609fb463@fleshgrinder.com>
Date: Wed, 8 Mar 2017 20:13:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-eE+23eBRhOqB6qtcnssGhdbx08K3jM52bHb4qXkys0Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [Discussion] is_string(), string type
 andobjectsimplementing __toString()
From: php@fleshgrinder.com (Fleshgrinder)

On 3/8/2017 7:50 PM, Nikita Popov wrote:
> On Wed, Mar 8, 2017 at 7:44 PM, Andrea Faulds <ajf@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