Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98426
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPhkiZzs=kLF-JKBjX4bVgADz+nonERWuZYiYo8cXA=GrXKU=g@mail.gmail.com>
References: <CAPhkiZzs=kLF-JKBjX4bVgADz+nonERWuZYiYo8cXA=GrXKU=g@mail.gmail.com>
Date: Wed, 8 Mar 2017 07:42:55 -0700
Message-ID: <CAObuZdteOTR-FEk5anLRSSeibtq8q+CjBQ+=sKUL0paTOVZYUg@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c04f74edcde4c054a3924c1
Subject: Re: [PHP-DEV] [Discussion] is_string(), string type and objects
 implementing __toString()
From: derokorian@gmail.com (Ryan Pallas)

--94eb2c04f74edcde4c054a3924c1
Content-Type: text/plain; charset=UTF-8

On Wed, Mar 8, 2017 at 5:25 AM, Andrey Andreev <narf@devilix.net> wrote:

> Hi all,
>
> I submitted a GitHub PR* to allow objects implementing __toString() to
> *optionally* pass is_string() validation. More verbose wording of my
> motivation can be seen in the PR description, but here are the main
> points:
>
> - Simpler way to do checks like: is_string($var) ||
> method_exists($var, '__toString')
> - Can be used for stricter string parameter validation in
> strict_types=0 mode (otherwise any scalar type is accepted)

- Can be used for looser string parameter validation in strict_types=1
> mode (__toString() objects aren't accepted there)
> - Regardless of the last 2 points, it is intentionally not limited to
> parameter types
>

If I understand correctly, you want the following to work:
declare(strict_type = 0);
function foo(string $bar) {



>
> * https://github.com/php/php-src/pull/2408
>
> ---
>
> I didn't have time to write this email right after submitting the
> patch, and in the meantime got some feedback from Fleshgrinder on
> GitHub, which I'll quote and address here:
>
> > Thanks for your effort and initiative.
> >
> > However, I strongly believe that this is the wrong approach. Adding a
> flag to a function directly results in the fact that the function violates
> the single responsibility principle. What we actually need to make this
> work is a "stringable" pseudo-type like the iterable type that was
> introduced in PHP 7.1. This "stringable" pseudo-type is the union of the
> scalar primitive string and any class that implements the __toString method.
> >
> > This has the advantage that we are actually able to use it together with
> strict_types, plus we have separate dedicated functions like
> "is_stringable" that adhere to the single responsibility principle. I
> actually wanted to create an RFC for that along with an implementation
> since iterable was accepted, but did not find the time yet.
> >
> > Closing note: these pseudo-types are necessary in PHP because it has no
> coherent type system, and there is nothing we can do about this in short
> term. Hence, adding such pseudo-types is the only short term solution that
> we actually have.
>
> I ultimately wouldn't care if it's a separate function and did in fact
> think of an is_stringable() function, but wasn't happy with the naming
> - who's to say that e.g. integers aren't stringable? Bar
> horribly-verbose names like
> "string_or_objects_implementing__toString", I don't think there's a
> way to avoid that ambiguity. :/
> If we want a "stringable" type though, I guess we'll have to live with
> that.
>
> I feel that debating the actual type system is way broader than I
> intended this to be, so I'll refrain from going further on that for
> now, as I've got some more radical ideas about it.
>
> ---
>
> Thoughts?
>
> Cheers,
> Andrey.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--94eb2c04f74edcde4c054a3924c1--