A re-introduction to JavaScript • Hacker News Board

Re: A re-introduction to JavaScript

#51

Post by jahewson » Sat, May 09, 2015, 5:07 PM UTC

snorrah wrote: post #27

The article says to watch out for 0.1 + 0.2 not exactly equalling 0.3 , so as a complete newbie to JavaScript, how do you work around this ?

Floating point numbers in any language are inaccurate, if you're performing say, financial calculations then you can use fixed point numbers by using scaled integers. For example:

    var SCALE = 100; // 0.01
    
    var a = 0+1 * SCALE;  // e.g. 2.5 would be 2+5 * SCALE
    var b = 0+2 * SCALE;
    
    if (a + b == 0+3 * SCALE) {
      // this will work...
    }

    console.log(a / SCALE);

Re: A re-introduction to JavaScript

#52

Post by ffn » Sat, May 09, 2015, 5:10 PM UTC

Whoa, the closure-based circular reference memory leak thing, is that just an IE issue or is that a language level (anti) feature? I need to know because I've very often done something like:

el$ = $('#whatever'); el$.click( function() { el$.find("a").css("color", "red"); } );

Re: A re-introduction to JavaScript

#53

Post by serve_yay » Sat, May 09, 2015, 5:34 PM UTC

barrkel wrote: post #33

serve_yay wrote: post #15

Earlier quoted context omitted.

I agree, `this` is a disaster. But, I just can't hardly think of another language where the people working in it mostly don't know the types. (Well, OK, PHP devs probably mostly don't) And I don't just mean run-of-the-mill blub programmers who dabble in jQuery, I mean some of the best devs I've ever seen in any language. I had a self-proclaimed JS expert tell me that JS has integers and floats as distinct types. Even…

"technically, functions are just objects that can be called" How can you create an object which can be called like a function, but will respond to 'typeof' with 'object' rather than 'function'? What happens when you try to call an object - what's the error? Try it, in a few of your favourite javascript interpreters: ({})() It seems clear to me that functions are more than "just" objects in JS. You can't start out wit…

> How can you create an object which can be called like a function, but will respond to 'typeof' with 'object' rather than 'function'?

You can't, by definition. Here is the relevant section of the ECMAScript 5 spec: http://www.ecma-international.org/ecma-262/5.1/#sec-11.4.3

Basically, an object which implements call will always cause `typeof` to return "function". But the broader point is that `typeof` will lie to you and you shouldn't trust it for, you know, determining the types of values. (For example, the type of null is null, but `typeof null` returns "object".)

As I noted above, this behavior of `typeof` is part of what causes the confusion around types in JS devs.

> You can't substitute an object where a function is expected - you get a type error - but you can substitute a function where an object is expected.

This is true, but not inconsistent with the notion that functions are objects which can be called. I encourage you to read the spec I linked above, or a draft of ES6.

Re: A re-introduction to JavaScript

#54

Post by serve_yay » Sat, May 09, 2015, 5:35 PM UTC

ahoge wrote: post #26

serve_yay wrote: post #19

Earlier quoted context omitted.

What could be more fun than a language that says the result of dividing by 0 is "Infinity"? It's a hoot!!

That's from IEEE 754 (a standard for floating-point arithmetic). `NaN` and -0 exist for the same reason.

I know, I was just joshing! Man, you guys really didn't like that one. Personally I enjoy taking a moment now and then to reflect on some of the sillier aspects of JS. This is because I love JS, not because I hate it.

Re: A re-introduction to JavaScript

#55

Post by BinaryIdiot » Sat, May 09, 2015, 5:44 PM UTC

TazeTSchnitzel wrote: post #50

BinaryIdiot wrote: post #24

Earlier quoted context omitted.

Yeah and not a big fan of them saying you can do for...in on an array while casually mentioning the limitation of doing such. I would consider it far better practice to NEVER iterating over an array with for...in.

Is there even any guarantee it would be iterated in the correct order?

Nope. Then again if you're doing a for...in you probably don't care about order.

Re: A re-introduction to JavaScript

#56

Post by serve_yay » Sat, May 09, 2015, 5:47 PM UTC

ahoge wrote: post #31

serve_yay wrote: post #25

Earlier quoted context omitted.

> Since calling constructor functions without `new` is generally an error The behavior of Number, Boolean, String, and Array is well-defined, it's safe to call them without new. In fact, in the case of String/Boolean/Number, calling them with new will often do something you don't expect. (Calling them with new gives you a Number/String/Boolean object , not primitive, which can cause trouble when you try to compare th…

> The behavior of Number, Boolean, String, and Array is well-defined, it's safe to call them without new. ES6 is packed with weird but well-defined things. The problem is that calling a constructor function (a PascalCase'd function) without `new` looks like an error because it generally is an error. To make matters worse, without closely examining that function, you cannot tell if it's an error. I do know that `Numbe…

That's fair, I just find them super useful in various situations, for example filtering over an array with Boolean to remove falsey values.

Re: A re-introduction to JavaScript

#57

Post by chris_wot » Sat, May 09, 2015, 5:52 PM UTC

sergiotapia wrote: post #29

chris_wot wrote: post #11

Earlier quoted context omitted.

Especially when you need to do something like: var that = this;

Looking at you Ember. Ugh! var controller = this; Every time!

They have to. There's a bug in the JavaScript spec that makes you do this :-) they are perfectly correct in doing what they are doing, if they didn't then funny thing would start to happen. Sad, but true.

Re: A re-introduction to JavaScript

#58

Post by chris_wot » Sat, May 09, 2015, 5:53 PM UTC

bryanlarsen wrote: post #13

chris_wot wrote: post #11

Earlier quoted context omitted.

Especially when you need to do something like: var that = this;

That's not generally necessary in ES6 when you use "=>" to define functions. Javascript is getting better...

It's really a minor criticism and I know ES6 resolves the issue :-)

Re: A re-introduction to JavaScript

#59

Post by barrkel » Sat, May 09, 2015, 5:54 PM UTC

serve_yay wrote: post #53

barrkel wrote: post #33

Earlier quoted context omitted.

"technically, functions are just objects that can be called" How can you create an object which can be called like a function, but will respond to 'typeof' with 'object' rather than 'function'? What happens when you try to call an object - what's the error? Try it, in a few of your favourite javascript interpreters: ({})() It seems clear to me that functions are more than "just" objects in JS. You can't start out wit…

> How can you create an object which can be called like a function, but will respond to 'typeof' with 'object' rather than 'function'? You can't, by definition. Here is the relevant section of the ECMAScript 5 spec: http://www.ecma-international.org/ecma-262/5.1/#sec-11.4.3 Basically, an object which implements call will always cause `typeof` to return "function". But the broader point is that `typeof` will lie to yo…

There's types as defined in a spec, and types according to type theory.

In short, I think the spec is incorrect in its use of the concept of types; or incomplete.

You'll note that the spec uses the concept of "internal properties" to distinguish between the different things one can do with values. From a type theory perspective, these internal properties and the implied permitted operations come close to type definitions. It's a matter of perspective, then, when one is using the word 'type' as defined by a particular language's spec, or 'type' as in programming language pragmatics / type theory POV. For the generalist programmer who knows more than one language, a broader concept of types is usually more useful.

Further, the spec uses these internal properties solely to define the semantics of the language, and they are not necessarily visible artifacts of any implementation. Talking about them as if they were concrete confuses the map with the territory.

Re: A re-introduction to JavaScript

#60

Post by z3t4 » Sat, May 09, 2015, 5:54 PM UTC

I think it's much easier to forget about "types" and think of objects instead. Trying to divide JavaScript objects into "types" will surely get you frustrated. If you absolutely want to check what "type" an object is, for example a sanity check for arguments passed to a function, you should make your own isMyType(obj) function and not rely on typeof or toString.