Re: [Discussion] is_string(), string type and objects implementing __toString()

On Sat, Mar 11, 2017 at 1:39 PM, Fleshgrinder <php@fleshgrinder.com> wrote: > On 3/10/2017 11:57 AM, Andrey Andreev wrote: >> Yes, they're valid string values, but the examples I gave were meant >> to show that context can make them predictably invalid, and hence why >> strict typing is desirable. > > I am totally in favor of strict types, but having a union of some type > and having the ability to constraint to it is strict. The union of > bool|int|float|null|string is stricter than the super type mixed. That's > the whole point of having a stringable. > We already have an unambiguous name for that: scalar > On 3/10/2017 4:11 PM, Andrey Andreev wrote: >> You don't, but I do care at times. > > Sorry, but your example makes no sense at all. Just because you got an > int does not even remotely mean that one of those constants was used. I'm sorry, I thought I wouldn't have to explicitly state that of course I don't know a constant was used ... "constant" is not a type. The important thing is that I know a constant was *not* used. Apparently, I am bad at examples, but take a look at sort(). Yes, even after I validate the $sort_flags values, I would never know if you passed int(1) or SORT_NUMERIC. However, knowing that no sane developer writes sort($array, 1), I can very reasonably tell you that the following is an error: $foo = '1'; sort($array, $foo); And the mere existence of SORT_FLAG_CASE makes it that much important that an error is triggered, as now my logic would be built with bitwise operations and I can't just check for one of X values. Ironically enough, the following code executes silently: $array = ['a', 'b', 'c']; sort($array, '2234234324'); If you don't see the problem with that, I guess it does make "no sense at all" from your POV. Just agree to disagree. Cheers, Andrey.