Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98466
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
To: Rowan Collins <rowan.collins@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
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>
 <CAPhkiZwr0Xff-+NR1OE7cnVD7AoHKRBR43h0S76TfWdrjK6kaA@mail.gmail.com>
 <d82c53bb-3e25-1d96-a2f0-82c29b8e753d@gmail.com>
Message-ID: <fc98e7a7-d7de-7ff6-16ce-442d0bb81b2d@gmx.de>
Date: Fri, 10 Mar 2017 11:19:03 +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: <d82c53bb-3e25-1d96-a2f0-82c29b8e753d@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [Discussion] is_string(), string type and
 objectsimplementing __toString()
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 09.03.2017 at 21:09, Rowan Collins wrote:

> On 08/03/2017 23:32, Andrey Andreev wrote:
>
>> 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.
> 
> OK, now we have some concrete examples, thanks. I would say that in
> these cases, what you actually want is a much tighter contract: not just
> "can be converted to string", but "intended to be used in this context".
> 
> It fits with what I was saying before about "if you can't name it, maybe
> it isn't the right abstraction". In this case, you want to accept some
> particular value objects but not, say, Exceptions - which are as useless
> for your purpose as an integer, even though (string)$foo would work fine
> on both.
> 
> So you want objects that have promised to behave appropriately for this
> context; that could be as simple as:
> 
> interface HTTPHeaderObject {
>     public function __toString();
> }
> 
> ....with appropriate documentation that objects declaring that they
> implement this interface promise to behave in a specific way when cast
> to string. This is much clearer than detecting __toString(), which only
> promises "I can be cast to string" - the same promise that is made by
> all scalar values.
> 
> In order to accept this or a string in a type hint, you need Union Types:
> 
> function setHeaderValue(string|HTTPHeaderObject $value) { ...

Or you could require the client to pass a respective string wrapper
which extends HTTPHeaderObject instead of a plain string.

-- 
Christoph M. Becker