Hi all, On Fri, Jan 23, 2015 at 8:05 PM, Andrea Faulds <a...@ajf.me> wrote:
> > On 23 Jan 2015, at 10:02, Alain Williams <a...@phcomp.co.uk> wrote: > > > >> On Fri, Jan 23, 2015 at 12:24:25AM +0000, Andrea Faulds wrote: > >> > >> Having it be the same as === would be inconsistent with our existing > sorting and comparison behaviour, so I don’t think it should be changed. If > we made it strict like that, we’d also have to define a strict < and > as > well, otherwise we have a problem, because in some cases ($x !== $y && !($x > < $y) && !($x > $y)) is TRUE. > > > > I think that you mentioned that you might come up with another RFC if > <=> is > > successful - that would be for a <==> operator. > > > > You might want to mention that ... but it is more complicated if the > operands > > are of different types - what does it return in that case ? FALSE ? But > the same > > as <=> if the types are the same ? > > The RFC did originally say that, Davey had thought of it. I'm not too keen > on the idea and have removed that bit: I don't really think you can do any > reasonable "strict" ordering. An error on unmatching types is a royal pain, > and I know this because I've had to deal with Game Maker Language which did > this. Sorting by type is fairly unintuitive. > > I think that if people want strict ordering, it's trivial to implement the > particular scheme they want using <=>, casts, type checks, or strcmp(). The only reasonable behavior for <==>, <==, >== would be raising error/exception if type differs. E_RECOVERABLE_ERROR may be used. If anyone write RFC for these operators, I'll vote +1. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
