"Approx-equal" operator

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Mon Dec 19 01:10:01 PST 2011

On 19.12.2011 2:26, Mike Samuel wrote:
> 2011/12/18 Dmitry Soshnikov<dmitry.soshnikov at gmail.com>:
>> On 18.12.2011 23:18, Mike Samuel wrote:
>>> 2011/12/17 Dmitry Soshnikov<dmitry.soshnikov at gmail.com>:
>>>> Hi,
>>>> Just recently was working with Ruby's code. And found useful again its
>>>> (actually from Perl) "approximately equal" operator: =~
>>> Perl's =~ operator is more comparable to String.prototype.match than
>>> RegExp.prototype.test.
>>> Perl operators can be used in either scalar or list contexts unlike
>>> ecmascript (see perldoc for wantarray) and it's true that =~ produces
>>> a boolean when used in a scalar context, but since match returns null
>>> on zero matches, it can still be used in conditions.  When used in a
>>> non-scalar context, =~ produces a list of the matches:
>>>      perl -e 'my $s = "foo"; print join ",", ($s =~ /o/g)'
>>> prints
>>>     o,o
>> Perhaps, I don't know Perl enough. The talk isn't about Perl though. We may
>> adjust the semantics for ES as _we_ wish, not Perl.
> I mistakenly assumed that you were claiming that a feature of your
> proposal was developer familiarity with similar syntax in other
> languages and that therefore it was worth understanding the semantics
> of those features in those other languages to avoid developer
> confusion.

No, no, my fault that I explained not so clear, sorry.

>>> Even ignoring order of evaluation, desugaring a ~= b to b.test(a)
>>> would cause the seemingly straightforward
>>>     var myRegex = /foo/g;  // Used for a global replace in other code.
>>>     if ("foo" ~= myRegex) { alert(1); }
>>>     if ("foo" ~= myRegex) { alert(2); }
>>>     if ("foo" ~= myRegex) { alert(3); }
>>> to alert 1 and 3 only.
>> Because of lastIndex, I understand. Though nobody says we have to directly
>> desugar it to .test(...) method. Obviously, it should handle the case
>> correctly.
> I know that you're just testing the waters before writing a strawman
> but I can't contribute except by weighing options.  In my opinion, as
> written, a desugaring based on .test is not the way to go.

I see, and this is OK since I mentioned the `test', and it's also OK "to 
test the water" in such case I think, since the feature is new for JS.

> <bikeshedding>I don't find the syntactic sugar that sweet.  ~=
> requires me to use the shift-key, so with paren-less calls,
> match/test/exec is clearer and not much longer.</bikeshedding>

Have we already planned paren-free calls? Seems I missed approved 
strawman. If so, then yes, we have to think whether we need ~=. After 
all, yes, it requires Shift to press and keys are in the opposite sides.


More information about the es-discuss mailing list