Comments on: A safety fence for your property lookups

By: matanlurey

matanlurey — Mon, 14 Jul 2008 22:51:16 +0000

@RichB
(object||{}).property is less efficient due to the fact than an anonymous object needs to be created – in a tight loop of hundreds of iterations it will be noticeable.

By: LeoHorie

LeoHorie — Mon, 14 Jul 2008 18:52:14 +0000

heh, so many different ways of accomplishing the same thing :)

@linb: I like your function. One could use a variadic function instead of passing a second parameter as an array for the extra sugar punch (i.e. so the function call looks like get(node, “nextSibling”, “className”) ), though I suspect some people might object with hypothetical performance issues with the body of the function itself.

By: MauriceSchoenmakers

MauriceSchoenmakers — Sun, 13 Jul 2008 18:57:22 +0000

compare :


       var r; if(node&&node.nextSibling&&(r=node.nextSibling.className)=='x') return r;
        var r; if((r=((node||0).nextSibling||0).className)=='x') return r;
        
        var r; if(r=node)if(r=r.nextSibling)if((r=r.className)=='x') return r;

Using a simple if is maybe a bit longer but faster :-)

By: KKFC

KKFC — Sat, 12 Jul 2008 11:15:48 +0000

Thanks your fenceï¼

By: RichB

RichB — Sat, 12 Jul 2008 09:58:46 +0000

This has been mentioned before with Oliver Steele’s Maybe Monads on the cheap where he recommends the following maybe monad null propagation behaviour:

(object||{}).property

http://osteele.com/archives/2007/12/cheap-monads

By: linb

linb — Sat, 12 Jul 2008 09:25:16 +0000

I use This get function:


get=function(hash,arr){
    for(var i=0,l=arr.length;i



By: eyelidlessness
eyelidlessness — Sat, 12 Jul 2008 03:31:37 +0000
@bosmeeuw, philm:

I think if, upon reading an explanation of what it does, you still find it unreadable, you’re probably doing something wrong.

.

@Nosredna:

I am on the fence; I think the “syntactic sugar” might eventually prove beneficial enough that the parens could become reflex.

.

As for || vs &&, first of all, if that’s your bottleneck, you need to rethink your approach. Second of all, just make sure you use the optimal condition order for your use case.



By: jguide
jguide — Fri, 11 Jul 2008 19:33:59 +0000
Well, unless speed was of the utmost importance, as in a game, wouldn’t this simply be a case where a try/catch block would be much clearer:


try{

     if (node.nextSibling.className == "something")

     // do something

}

catch(e) {

     // catch error

}





By: Nosredna
Nosredna — Fri, 11 Jul 2008 19:17:24 +0000
Also, sometimes these tricks are useful for people writing compilers that target JS as an assembly language. Shorter is usually better in those cases. You might generate the more typical code for debugging and the tighter code for production.

.

Another problem, though, is that the && will shortcut out, so it’s probably faster than the || solution.



By: Nosredna
Nosredna — Fri, 11 Jul 2008 19:14:14 +0000
It is shorter, and I don’t find it unreadable at all. I know right away when I see it that the programmer is trying to guard against a missing attribute.

.

But I don’t think I’d do it (for me, the less parens the better).

.

I do like to see these things, though. Good for the brain.



By: philm
philm — Fri, 11 Jul 2008 14:13:23 +0000
if (((node || 0).nextSibling || 0).className == 'hello') 

if (node && node.nextSibling && node.nextSibling.className == 'hello') 

The 'neat trick' isn't that much shorter and a lot less readable! Must agree with bosmeeuw


By: bosmeeuw
bosmeeuw — Fri, 11 Jul 2008 13:38:31 +0000
Nice, this turns the if clause which clearly expresses that the developer expects node or node.nextSibling to possibly be null into an clever/unreadable hack! If only more people properly abused language constructs this way..