Re: [RFC] Comparison and conversion inconsistency - need more info

Sanford Whiteman wrote (on 10/11/2013):

I didn't immediately spot it, but the word "comparable" next to each argument in the Parameters section is linked to the comparison operators page. It mgiht be an idea to add it to the See Also section as well, to make it more visible.

Don't see how this has any more of a visibility problem than mixed type params for other functions.

Well, "mixed" is a pseudo-type used consistently throughout the manual and linked to an explanation of the term here: http://php.net/manual/en/language.pseudo-types.php The fact that a particular value has to be "comparable", on the other hand, doesn't really tell you how the different parameters interact, so the link has poor "information scent" - I'd probably click there if my values were being rejected, but not if certain *combinations* were behaving "oddly". The reason I suggested a "See also" is that it's unobtrusive, but can include clear text as to why you might want to look at it. Actually, now I look, most of the other text specifically talks only about numeric (e.g. the "Return Values" section: "min() returns the numerically lowest of the parameter values" which is just plain wrong) or alphanumeric (in the "Note:" within the "Description" section) values. This could easily reinforce the kind of mistake made here of thinking that everything is cast to int (or possibly string) before comparison.

IMO, it's a nice convenience that the hyperlink is there, but not even necessary. min(<list>) should be assumed to be sort(<array>) and unshift(<array>). Sort --> comparison --> comparison rules apply.

That's certainly an intuitive explanation, but it's by no means the only way of implementing or imagining the underlying algorithm. It would be one way of making clear what happens though: "This function is equivalent to sorting the items based on the [link]standard type comparisons[/link] and returning the first item." You don't have to think the current documentation is awful to find ways of improving it. Regards, -- Rowan Collins [IMSoP]