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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
