Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98448
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <24efb0e7-b0e3-68ed-5f42-2d5481f8f291@gmail.com>
References: <CAPhkiZzs=kLF-JKBjX4bVgADz+nonERWuZYiYo8cXA=GrXKU=g@mail.gmail.com>
 <f60b8e05-c5d8-0437-37b5-a4b23911fdbb@fleshgrinder.com> <fb25f8bc-2b7c-a27d-6861-039b67c19971@gmail.com>
 <CAPhkiZzus6-LW8g-fxeBYymEq2FGLOfMS2DKZ16KPOXfaxr+AQ@mail.gmail.com> <24efb0e7-b0e3-68ed-5f42-2d5481f8f291@gmail.com>
Date: Thu, 9 Mar 2017 01:32:50 +0200
Message-ID: <CAPhkiZwr0Xff-+NR1OE7cnVD7AoHKRBR43h0S76TfWdrjK6kaA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [Discussion] is_string(), string type and objects
 implementing __toString()
From: narf@devilix.net (Andrey Andreev)

On Thu, Mar 9, 2017 at 12:42 AM, Rowan Collins <rowan.collins@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 <php@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.