That's part of why I suggested it... My mention of Object.* Was mainly that it could defer to a common base class/constructor implementation for comparison. And that a string and number implementation should be provided...
I'm also good with having non-matching types return undefined while matching types is a Boolean. Object.* could just defer to the prototype implementation of the first value.. null or undefined always returning undefined. -- Michael J. Ryan - [email protected] - http://tracker1.info Please excuse grammar errors and typos, as this message was sent from my phone. On Apr 12, 2017 7:04 AM, "Darien Valentine" <[email protected]> wrote: > > Personally I think `a < b` should just become a compile error if the > types are not number. > > Breaking stuff aside, I think this is an important point. The fact that > the LT/GT operators do work on strings is a source of bugs. As with default > sort, I’ve seen code written a number of times where it was evident the > author expected the behavior would be more like `Intl.Collator.prototype. > compare`. > > Unless I’m missing some important common use case for comparing strings > based on byte values (`assert('a' > 'B')`), I think `Number.gt`, > `Number.gte`, `Number.lt`, `Number.lte` would be a good solution. > > On Wed, Apr 12, 2017 at 5:09 AM, T.J. Crowder < > [email protected]> wrote: > >> > Personally I think `a < b` should just become a compile error if the >> types are not number. TypeScript? >> >> I'm not following you. JavaScript variables don't have types, so it can't >> become a compile-time error; and making it one would *massively* break the >> web. (Yes, you can use TypeScript to get types if you like, but we're not >> talking about TypeScript.) >> >> > ...that's a separable concern which should not be part of the >> operator's behaviour IMO... >> >> There's no talk of changing how `<` and `>` (or `<=` and `>=`) work. >> >> But just as we have `==` (loose, coercing) and `===` (strict, >> non-coercing), the discussion is about having strict non-coercing versions >> of `<`, `>`, `<=`, and `>=`. >> >> -- T.J. Crowder >> >> >> On Wed, Apr 12, 2017 at 10:00 AM, Alexander Jones <[email protected]> wrote: >> >>> Personally I think `a < b` should just become a compile error if the >>> types are not number. TypeScript? >>> >>> If you want to also check that they are both number (that's surely what >>> we mean here and not that they are both string!) and return `false` if not, >>> that's a separable concern which should not be part of the operator's >>> behaviour IMO. It would appear to just mask fundamental typing errors, >>> unless I am missing some perspective? >>> >>> Alex >>> >>> On Wed, 12 Apr 2017 at 09:02, T.J. Crowder < >>> [email protected]> wrote: >>> >>>> Grr, there's always something. I forgot to mention that solving this >>>> with functions is an option because short-circuiting isn't an issue, both >>>> operands have to be evaluated by these relational operators anyway. So >>>> unlike the motiviations for infix functions or macros or whatever, we don't >>>> have that issue here. >>>> >>>> -- T.J. Crowder >>>> >>>> >>>> On Wed, Apr 12, 2017 at 8:56 AM, T.J. Crowder < >>>> [email protected]> wrote: >>>> >>>> Very interesting stuff so far. >>>> >>>> My take on some options, organized into sections: >>>> >>>> * Solving it in userland >>>> * Using symbolic operators >>>> * Using functions >>>> * Using non-symbolic operators >>>> >>>> # Solving it in userland: >>>> >>>> Anyone wanting strict relational operators today can readily give >>>> themselves functions for it: >>>> >>>> ```js >>>> const lt = (a, b) => typeof a === typeof b && a < b; >>>> ``` >>>> >>>> Usage: >>>> >>>> ```js >>>> if (lt(a, b)) { >>>> // ... >>>> } >>>> ``` >>>> >>>> So the question is whether the value of having a standard way of >>>> expressing this is worth the cost of adding it? >>>> >>>> Playing into that is that various options come with varying costs: >>>> >>>> * Using symbolic operators has a cost, but doesn't change fundamentals; >>>> I'm not an implementer, but I'd think the cost would be fairly low (but >>>> non-zero). *Any* syntax change rattles parsing cages everywhere, but syntax >>>> changes are now fairly regular occurrences in JavaScript. >>>> * Using functions means no new syntax, which means not rattling parsing >>>> cages, and are polyfillable. >>>> * Using non-symbolic operators rattles cages, and probably more >>>> significantly than new symbolic ones, and has been rejected in the past >>>> (`is`/`isnt`). >>>> >>>> So that's in the mix. >>>> >>>> # Using symbolic operators: >>>> >>>> ## Form >>>> >>>> The closest I can come to consistency with `==`/`===` and `!=`/`!==` is: >>>> >>>> Loose Strict >>>> == === >>>> != !== >>>> < <=< >>>> > >=> >>>> <= <== >>>> >= >== >>>> >>>> We can think of the `=` in the middle as being what signifies the >>>> strict type aspect. The second `<` and `>` on `<=<` and `>=>` are a hack, >>>> but a reasonable hack that's in the spirit of the original two strict >>>> operators. :-) >>>> >>>> ## Semantics >>>> >>>> Because they're like `!==` and `===`, their semantics would have to be >>>> in line with `!==` and `===`: The result is `true` if the operands are of >>>> the same type and the relation is true, `false` otherwise. >>>> >>>> # Using functions: >>>> >>>> ## Form >>>> >>>> Given `Object.is(value1, value2)` there's an argument for putting these >>>> on `Object` as well. But `Object` is an odd place for them (and indeed for >>>> `is`). Perhaps we need a place for these to go. But sticking with `Object` >>>> for now: >>>> >>>> ```js >>>> Object.lt(value1, value2) >>>> Object.gt(value1, value2) >>>> Object.lte(value1, value2) >>>> Object.gte(value1, value2) >>>> ``` >>>> >>>> So: >>>> >>>> ```js >>>> if (Object.lt(a, b)) { >>>> // ... >>>> } >>>> ``` >>>> >>>> Verbose, and again, using `Object` if I'm comparing numbers or strings >>>> seems wrong. But it's consistent with the prior practice of `Object.is`. >>>> >>>> Michael J. Ryan suggested putting them on `Number`, `String`, and >>>> `Object` instead, on the theory that if you're being strict, you know what >>>> you're comparing. I'm not sure I agree that you do (a generic "take the >>>> lower of these two" function, for instance), but there's something there. >>>> It doesn't address the verbosity issue. (Presumably we only need `Number` >>>> and `String` though, unless we're going to introduce a whole mechanism for >>>> relational comparison of objects. Or unless the `Object` version just hands >>>> off to the `Number` or `String` version based on the first operand type.) >>>> >>>> ## Semantics >>>> >>>> Using functions gives us the opportunity to use slightly different >>>> semantics: >>>> >>>> 1. `true`: The operands are the same type and the relation is true >>>> 2. `false`: The operands are the same type and the relation is false >>>> 3. `undefined`: The operands are of different types >>>> >>>> This takes advantage of the fact `undefined` is falsy to not get in the >>>> way of people just using the result in a condition, but if they examine the >>>> result itself, it's possible to differentiate between #2 and #3. >>>> >>>> Sadly, `Object.is` (the exposed version of the SameValue algorithm) >>>> does not make this distinction. >>>> >>>> # Non-symbolic operators >>>> >>>> JavaScript already has at least one binary operator that isn't >>>> symbolic: `in`. Maybe there's a case for adding more. Brendan Eich is [on >>>> record](https://esdiscuss.org/topic/suggestion-mapping-symbo >>>> lic-infix-ops-to-binary-functions#content-5) five years ago as having >>>> issues with them: >>>> >>>> > > modulo, div, divmod, has, extends >>>> >>>> > These are much better as methods. Polyfillable, but also not subject >>>> to weird line terminator restrictions on the left. Same arguments killed >>>> is/isnt. >>>> >>>> Hence `Object.is`, presumably (the linked discussion was about infix >>>> functions, not `is`). I don't know if that view has shifted in the >>>> subsequent five years; there have been big changes in the way JavaScript >>>> moves forward. But that was an objection at least then. >>>> >>>> ## Form >>>> >>>> `lt`, `lte`, `gt`, and `gte`. And while we're at it, `eq` and `noteq`. >>>> So: >>>> >>>> ```js >>>> if (a lt b) { >>>> // ... >>>> } >>>> ``` >>>> >>>> To avoid breaking the web, the new non-symbolic operators would have to >>>> remain valid identifiers, only being operators by context, a bit like how >>>> `for` can be a literal property name (`obj.for`) as of ES5 because we know >>>> from context that it's not the `for` statement. But I assume (not being a >>>> parser guy) that it's more complex to handle the above (those "weird line >>>> terminator conditions on the left" Eich mentioned). >>>> >>>> ## Semantics >>>> >>>> Like functions, non-symbolic operators let us consider slightly >>>> tweaking the semantics, e.g. that `undefined` result for operands of >>>> different types I mentioned earlier. >>>> >>>> # Wrap-up thoughts >>>> >>>> Unless it's left to userland, the simplest, least cage-rattling >>>> approach is to add functions to `Object`, but it's also ugly to use. It >>>> does have the benefit (in my view) of letting us tweak the return value >>>> when the types don't match. >>>> >>>> It seems to me the second least cage-rattling is to add symbolic >>>> operators consistent with `===` and `!==`. >>>> >>>> -- T.J. Crowder >>>> >>>> On Wed, Apr 12, 2017 at 7:05 AM, Michael J. Ryan <[email protected]> >>>> wrote: >>>> >>>> Thinking on it... (Number|Object|String) .strict(Equal|Greater|Less...) >>>> Methods (a, b) might be better... If either value isn't a match for the >>>> bound type, it's a false, even if both sides are equal... >>>> >>>> Ex,. >>>> >>>> Number.strictEqual(null, null) false >>>> >>>> Object.strictEqual(1, 1) false >>>> ... >>>> >>>> If you're doing a strict compare, one can presume you should know what >>>> you're comparing. >>>> >>>> >>>> -- >>>> Michael J. Ryan - [email protected] - http://tracker1.info >>>> >>>> Please excuse grammar errors and typos, as this message was sent from >>>> my phone. >>>> >>>> On Apr 11, 2017 10:46 PM, "felix" <[email protected]> wrote: >>>> >>>> Maybe every operator can have a non-coercing variant? >>>> >>>> One possible syntax is to have a modifier on operators >>>> x = a (<) b (+) c (&&) (!)d; >>>> if (x (!=) y) ... >>>> >>>> Another possible syntax is to have a modifier on expressions >>>> x = #(a < b + c && !d) >>>> if #(x != y) ... >>>> >>>> On Tue, Apr 11, 2017 at 7:48 PM, Darien Valentine < >>>> [email protected]> wrote: >>>> > Although I’m unsure if this is wise given there are already eleven >>>> symbols >>>> > that are combinations of `=` and `<`/`>`, for symmetry with `==` and >>>> `===` >>>> > I’d imagine something like this: >>>> > >>>> > ``` >>>> > COERCIVE STRICT >>>> >> =>= >>>> > < =<= >>>> >>= =>== >>>> > <= =<== >>>> > ``` >>>> > >>>> > Could also follow the pattern `>==` (strict GT) and `<===` (strict >>>> GTE), >>>> > which avoids the awkwardness of the latter two sharing opening chars >>>> with >>>> > `=>`, but that seems more ambiguous since `>==` doesn’t let you infer >>>> > whether it means strict GT or strict GTE. >>>> > >>>> > It’d be nice to have this functionality built in, but I wonder if it’d >>>> > possibly be preferable to provide it through methods of one of the >>>> built-in >>>> > objects, rather than as operators. Functions after all are more >>>> flexible. >>>> > >>>> > _______________________________________________ >>>> > es-discuss mailing list >>>> > [email protected] >>>> > https://mail.mozilla.org/listinfo/es-discuss >>>> > >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
