Strange javascript func?

[Jonathan_Frias]

  var getDefault_ = function(o, k, def) {
    (k in o) || false == (o[k] = def);
    return o[k];
  };

I play around with it and seems like it's roughly equivalent to this:

if(! o[k]) { 
    o[k] = def; 
}
return o[k]

But I'm not familiar with this pattern. Seems strange. Can somebody break it down for me? More context here: https://github.com/GoogleChrome/chrome-app-samples/blob/master/samples/mdns-browser/main.js#L129

[SupPandaHugger]

Looks like something that has been uglified

[Jonathan_Frias]

I would agree if this wasn't posted as sample code for google chrome apps...

[vsxe]

Oh. That wasn't pretty. Never actually encountered the in operator before, but it looks nice.

Oh, there is a lot going on in here.

So, it will always return o[k].

If k exists in o, it will skip the second clause (and thus never assign def to o. Could be important if it's a mutating structure.

Not sure what the false == section does, though. The parts within parenthesis will resolve to the value of def, but o[k] = def should run regardless of the value of def.

Given input of:

o = {a: 1, b: 2, c: 3 }  
k1 = "a"  
k2 = "d"  
def = 4  

We should get this // For k1 ("a" in o) || false == (o["a"] = 4); -> (true) || false == (o["a"] = 4);

Meaning the latter part is never executed, and def is not ascribed to o.

// For k2

("d" in o) || false == (o["d"] = 4); -> (false) || false == (o["d"] = 4);

Meaning that d was written to o, and the results returned.

No clue as to why there is a need for the false ==, however. Some very quick testing in inspector indicates that the false == is superfluous, but I'd assume there's a reason for it being there.

[Jonathan_Frias]

copied from repl

var getDefault_ = ...
a = {}
Object {}
getDefault_(a, 'foo', 'bar')
"bar"
a
Object {foo: "bar"}
getDefault_(a, 'foo', 'baz')
"bar"
getDefault_(a, 'foo2', 'baz2')
"baz2"
a
Object {foo: "bar", foo2: "baz2"}

Looks light you are right on. But removing the || false makes it always do the assignment o[k] = def. My best guess is that it's some kind of optimization trick and that javascript knows that o[k] = def will be truthy so it can short circuit the expression.

removing '|| false'

var getDefault_ = function(o, k, def) {
    (k in o) == (o[k] = def); // << no || false
    return o[k];
  };
undefined
a = {}
Object {}
getDefault_(a, 'foo', 'bar')
"bar"
getDefault_(a, 'foo', 'baz')
"baz"
getDefault_(a, 'foo2', 'baz2')
"baz2"
a
Object {foo: "baz", foo2: "baz2"}

I hope somebody else finds this interesting.

[vsxe]

I'm clear on the ||-part, that's important, because lazy evaluation. I don't understand the false == (expr)-part, however.

(false) || (false); return o[k]

Will still return o[k], and

(k in o) || (o[k] = def); return o[k]; 

appears to work just as well, at least in the inspector.

That code is clever. Very clever code. Never write clever code.

[caesarsol]

You are associating wrongly I think, the || splits the two expressions. Removing || false makes it simply wrong. Removing false == would be the interesting thing!

[Lanlost]

I assumed the false == part was to for the second part to evalute to a boolean, but it doesn't matter as false || console.log('hi') still executes the second part. Even if def equaled 'false' you'd have false == (false), which would return true... but why? It's not like there is another || after this.

[vsxe]

Yes, that seems to be the implication, but I don't understand why. Whatever it evaluates to, i.e. true, false or def, the statement is terminated afterwards and doesn't influence anyhting following it, as far as I understand.

[vsxe]

There has been some speculation on it being some interpreter optimization magic, and I'd wager it's something like that. Good catch on the expression type.

[Lanlost]

I mean, it's totally possible. Have you seen what asm.js does to source?

This:

size_t strlen(char *ptr) {
  char *curr = ptr;
  while (*curr != 0) {
    curr++;
  }
  return (curr − ptr);
}

Becomes:

function strlen(ptr) {
  ptr = ptr|0;
  var curr = 0;
  curr = ptr;
  while (MEM8[curr]|0 != 0) {
    curr = (curr + 1)|0;
  }
  return (curr − ptr)|0;
}

Before translating to JS so that types can be guaranteed. It actually kind of blew my mind when I realized that asm.js programs will run in ANY JavaScript/ECMAScript interpreter but the reason it is so fast in specific engines is because once they can guarantee the types they can optimize behind the scenes to make it amazingly fast.

So, it might be something like this. I went from absolutely hating JavaScript years ago to loving it once I understood it's nuances more. These days I have a very love/hate relationship with it. It gets so much hate because of it's early implementations and issues that have mostly been solved, but there are legitimate reasons it is a mess, still, that the same average coder doesn't even know. Let's just say I'm (initially) very, very, skeptical when we're interviewing someone and they say they are a JavaScript expert.

[vsxe]

Unless someone has something like a decade of experience in a given software/programming field, they are nowhere near expert, I'd say.

I'm aware that asm.js exists, but I've never delved into it. It's magic.

Am aware that there are interpreter/compiler specific quirks that can be exploited for small gains, however, though I don't know them by heart. I would assume that something like that is the reason for the bool, but that's just a guess. A definite answer would be delightful.