How are you using this pattern in a real world app? Are you looping through a list of links in a domready event or what is the use case?
Seems that you wouldn't need this pattern if you had a Class based approach to this. On Apr 23, 10:32 am, Lewis <[email protected]> wrote: > Wow thanks for the interesting conversation. Whilst I can see the > reasoning behind both sides of the argument, to me it's cleaner and > more convenient to tell the bind function to return false, than it is > to create anonymous functions for it. Don't forget, a lot of the time > people will have to bind the anonymous function, which looks even more > messy. Eg: > > function(){ > this.doSomething(); > return false; > > }.bind(this); > > Compared to: > this.doSomething.returnFalse(this); > > Although perhaps a better design would be to allow the 3rd argument of > bind (and similar functions) to be an explicit return value. Or even > just allowing an explicit return value in function.create so people > can create their own wrapper functions (and it would only add a few > bytes of extra code). > > Lewis. > > On Apr 22, 11:16 pm, Sanford Whiteman <[email protected]> > wrote: > > > > addEvent('click',function(){return f() && false;}) > > > amounts to the same thing. > > > I know it's the same as > > > f(); return false; > > > but it might be more easily interpreted as wrapping the function and > > its forced-false return in one, and that's closer to what the OP was > > wondering about (the two-at-once/wrapper concept). > > > > I still don't see the need here. "return false" is just not that big > > > of a burden. > > > Me neither, just playing with other ways.... > > > --Sandy
