On 3/9/2017 12:32 AM, Andrey Andreev wrote:
> On Thu, Mar 9, 2017 at 12:42 AM, Rowan Collins <rowan.coll...@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.
>
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.
On 3/9/2017 12:32 AM, Andrey Andreev wrote:
> On Thu, Mar 9, 2017 at 12:43 AM, Fleshgrinder <p...@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.
>
All of these can work with any other scalar value that was coerced to a
string. I actually think that most examples given will have dedicated
strictly typed methods to ensure that the value is correct for their
domain. Don't forget that a string in PHP is a binary buffer and may
contain pretty much every kind of malicious stuff that you never wanted
or expected. Validation is absolutely necessary at all times when
dealing with strings. Having an integer that is converted to a string
does not make strings more evil than they already are.
You actually already need to deal with all kinds of data that gets
coerced, since you have no control over the strict mode of the caller. ;)
On 3/9/2017 12:32 AM, Andrey Andreev wrote:
> 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.
>
I actually consider the existence of almost all magic methods as a
hindrance for evolving the language, and definitely do not desire to get
more of them into core. Having a `DateTime::toTimestamp()` is much more
valuable than a `DateTime::__toInteger()`.
These magic methods are a result of the incoherent type system. Treating
the symptoms instead of the root cause. The story would be different if
a `Timestamp` could extend `Integer` which would directly allow it to be
passed to all functions that are capable of dealing with an `Integer`.
(Or any other possible constellation of a more sophisticated type system.)
--
Richard "Fleshgrinder" Fussenegger
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
