Re: [Discussion] is_string(), string type and objects implementing __toString()
| From: | Fleshgrinder | Date: | Thu, 09 Mar 2017 17:47:44 +0000 |
| Subject: | Re: [Discussion] is_string(), string type and objects implementing __toString() | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-98459@lists.php.net to get a copy of this message | ||
On 3/9/2017 12:47 PM, Andrey Andreev wrote:
> Hi,
Hey :)
On 3/9/2017 12:47 PM, Andrey Andreev wrote:
> On Thu, Mar 9, 2017 at 1:49 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
>> Stringable seems very explicit and strict to me, since it is opt-in.
>> Currently there is no way to have the ergonomics of coercion if strict
>> mode is active for a file. This could be a very explicit way to enable
>> it for portions.
>>
>
> I don't understand what you're trying to say here, or rather what you
> mean by "stringable" at this point ... Is it a compound type for
> string and __toString() objects only, or not? Your last comments
> suggest that it isn't.
All scalars, null, and objects with a __toString are stringable. I
argued at first that we should only bridge string and objects with a
__toString but later came to the conclusion that it does not add value.
I understand that this might be confusing, since there are right now
many messages in this thread.
On 3/9/2017 12:47 PM, Andrey Andreev wrote:
> How can "any other scalar value" work? Using the cookie and headers examples:
>
> - booleans can be used as On/Off flags for the secure and httpOnly
> cookie attributes, but aren't valid literal values for any of the
> attributes, or any HTTP header.
> - integers are valid as a few headers' values - that is true, but
> certainly in a minority of cases
> - floats may be used for the q(uality) attribute in content
> negotiation (and nothing else AFAIK), but that is a very, very narrow
> domain
> - null is obviously invalid ... who sends an empty header? And if you
> have a use case where you do want to use them, we can already make
> anything nullable
>
> Of course the string values should be validated, unless you want to
> allow setting arbitrary headers, e.g.:
>
> abstract function setHeader(stringable $name, stringable $value);
>
> ... but filtering out the known to be invalid types *is* validation.
> And just that much better if it happens at compile time.
Because:
- bool(true) = '0'
- bool(false) = '1'
- int(n) = 'n'
- float(n) = 'n'
- null = ''
- object(s) = 's'
- string(s) = 's'
All values are possible values that I can pass to you if you use the
string type constraint. Hence, all these types are valid string values
if you request a stringable.
Stringable should work exactly like the string constraint in non-strict
mode, but regardless of the strict mode. The difference to a scalar type
constraint is that the passed values are always converted to a scalar
string, hence, the source type is unknown to the receiver.
As you can see, it does not matter if the stringable pseudo-type accepts
more than just string and objects with a __toString method.
--
Richard "Fleshgrinder" Fussenegger