Simplify equality checks and get rid of unreachable code in number and bool.

Simplify equality checks and get rid of unreachable code in number and bool.


BUG=
TEST=

Committed: https://code.google.com/p/dart/source/detail?r=3432

[kasperl, 2012-01-19 10:18:42]

I'll stop hacking on this now, but I couldn't resist simplifying the EQ checks a
bit (faster and more correct).

Before this change, if we ever ended up comparing a string with a string
wrapper, we would always claim that they weren't equal because we would call
String.prototype.EQ$operator() with the argument being a string wrapper so the
typeof(other) == 'string' check would fail.

I still find it uncomforting to have both string values and wrapped strings
floating around.

[floitsch, 2012-01-19 11:31:59]

LGTM!

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
File compiler/lib/implementation/core.js (right):

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
compiler/lib/implementation/core.js:337: return (typeof val1 != 'object')
what if val1 is a native string and val2 is a boxed string?

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
compiler/lib/implementation/core.js:343: return (typeof val1 != 'object')
ditto.

[kasperl, 2012-01-19 11:42:59]

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
File compiler/lib/implementation/core.js (right):

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
compiler/lib/implementation/core.js:337: return (typeof val1 != 'object')
On 2012/01/19 11:31:59, floitsch wrote:
> what if val1 is a native string and val2 is a boxed string?

Good point. This code behaves the same (broken) way as the old code and always
return false in this case. It seems that I've only fixed the case where you're
comparing two wrappers.

[ahe, 2012-01-19 13:27:15]

DBC

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
File compiler/lib/implementation/number.js (right):

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
compiler/lib/implementation/number.js:6: function
native_NumberImplementation_BIT_OR(other) {
Any method that starts with native_ and immediately calls another native_ method
is unnecessary as far as I can tell.

If you get rid of these methods, perhaps you can get rid of
_NumberJsUtil._throwIllegalArgumentException as well. Then you have reduced the
size of generated code.

[kasperl, 2012-01-19 13:33:10]

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
File compiler/lib/implementation/number.js (right):

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
compiler/lib/implementation/number.js:6: function
native_NumberImplementation_BIT_OR(other) {
On 2012/01/19 13:27:16, ahe wrote:
> Any method that starts with native_ and immediately calls another native_
method
> is unnecessary as far as I can tell.
> 
> If you get rid of these methods, perhaps you can get rid of
> _NumberJsUtil._throwIllegalArgumentException as well. Then you have reduced
the
> size of generated code.

Yes -- strongly agreed. That is certainly the plan. I've grouped all the
functions that we can simplify even further at the top of this file.

[mmendez, 2012-01-19 17:09:47]

lgtm

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
File compiler/lib/implementation/string.js (right):

https://chromiumcodereview.appspot.com/9192007/diff/1/compiler/lib/implementa...
compiler/lib/implementation/string.js:22: // strings floating around. The
usually stem from referencing [this]
Nit: the -> they.