4 ms·

I love closures. I can't live without them. And I never, ever, use them to replace a for loop. Approaching closures from the "because they can replace loops in

I love closures. I can't live without them. And I never, ever, use them to replace a for loop. Approaching closures from the "because they can replace loops in great ways!" is IMO pretty boneheaded. Let's take something from iOS land, where blocks (Obj-C closures) make my life easier than it ever has been before. If you want to hide an object, then destroy it once its hidden: [UIView animateWithDuration:0.2 animations:^{ myObj.position.x += 10.0; } completion:^(BOOL finished) { [myObj destroy]; }]; How would you implement this without closures? How much of a clusterfuck will it be? Will you have to install something that will poll for the animation to be finished? Will you write a big "animation manager" class that will throw around a bunch of function pointers and callbacks and marshall all of your animations for you? Will you have to declare a load of protocols and support classes just to implement said callbacks? The biggest boon to closures, for "regular" programmers, is the dramatic simplification of async code.

cbo 15y ago
I don't know a lick of iOS or Obj-C, but this line is absolutely true: > The biggest boon to closures, for "regular" programmers, is the dramatic simplification of async code. Consider the way it's currently done in Java: listener.addCallback(new AsyncCallback<ReturnType>(Parameters ..) { public void onSuccess(ReturnType returned) { System.out.println("Successfully returned!"); } public void onFailure(Throwable thrown) { System.out.println("Unsuccessfully returned!"); } }); This is unbelievably ugly, and yet this is about as easy as it gets in Java. In order to make asynchronous callbacks "easier" you have to instantiate an anonymous class with very precisely named methods. It's not only wasteful, but the potential for error is huge. Closures could make this much, much simpler.
- eta_carinae 15y ago
  You also need to do this with closures if you have more than one method.
jsankey 15y ago
> How would you implement this without closures? You don't have to look too far to find out: blocks haven't always been supported, and the older animation APIs still exist on UIView. You need to set a completion callback selector instead of passing a block. It's certainly uglier, on both sides of the API, but particularly on the implementation side. Blocks wrap up the state they need by default (well, for the majority of cases) which saves a lot of tedious work.
yummyfajitas 15y ago
In a language without closures [1], you'd do something like this: class __AnimationHandler(superclass): def __init__(self, obj): self.obj = obj def animations(self): self.obj.position.x += 10.0 def onCompletion(self, finished): self.obj.destroy() ui_view.animateWithDuration(0.2, handler=__AnimationHandler) Although I definitely prefer closures, this is hardly a clusterfuck. But it would be fuglier in C/C++. [1] Yes, python has closures, which obey confusing rules and often work. But the pythonic way is an object handler.
- lucian1900 15y ago
  Python's closures are exactly like, say, scheme's, except that bindings are local by default.
  - yummyfajitas 15y ago
    No, they aren't exactly the same: x = 0 def foo(): x = x + 1 print x UnboundLocalError: local variable 'x' referenced before assignment The javascript version works fine. var x = 0; var foo = function() { x = x + 1; console.log(x); } I realize there are ways around this, but they are considered unpythonic. For example: x = [0] def foo(): x[0] = x[0] + 1 print x[0] This works as you'd expect.
    - lucian1900 15y ago
      As I said, except that bindings are local by default. Python3's nonlocal allows explicit enabling of scheme-like behaviour.
LinaLauneBaer 15y ago
Animations were possible before blocks appeared. The non-block-based APIs is still around: -beginAnimations:context: -commitAnimations etc. The "completion" feature can be implemented via delegating. One thing to note here is: If you don't need the completion block you can also just write: myObj.position.x += 10.0 without blocks at all. At least on OS X every animatable object as an animator proxy that works like this: [myObj animator].position.x += 10.0; Then an implicit animation kicks in that can be configured. The default implicit animation duration is 0.25s but this can all the configured. The original Core Animation (without blocks) made working with animations so much easier and cooler. You could do everything you can do with the blocks API - although the blocks API is much nicer of course.

cbo 15y ago

I don't know a lick of iOS or Obj-C, but this line is absolutely true: > The biggest boon to closures, for "regular" programmers, is the dramatic simplification of async code. Consider the way it's currently done in Java: listener.addCallback(new AsyncCallback<ReturnType>(Parameters ..) { public void onSuccess(ReturnType returned) { System.out.println("Successfully returned!"); } public void onFailure(Throwable thrown) { System.out.println("Unsuccessfully returned!"); } }); This is unbelievably ugly, and yet this is about as easy as it gets in Java. In order to make asynchronous callbacks "easier" you have to instantiate an anonymous class with very precisely named methods. It's not only wasteful, but the potential for error is huge. Closures could make this much, much simpler.

eta_carinae 15y ago
You also need to do this with closures if you have more than one method.

jsankey 15y ago

> How would you implement this without closures? You don't have to look too far to find out: blocks haven't always been supported, and the older animation APIs still exist on UIView. You need to set a completion callback selector instead of passing a block. It's certainly uglier, on both sides of the API, but particularly on the implementation side. Blocks wrap up the state they need by default (well, for the majority of cases) which saves a lot of tedious work.

yummyfajitas 15y ago

In a language without closures [1], you'd do something like this: class __AnimationHandler(superclass): def __init__(self, obj): self.obj = obj def animations(self): self.obj.position.x += 10.0 def onCompletion(self, finished): self.obj.destroy() ui_view.animateWithDuration(0.2, handler=__AnimationHandler) Although I definitely prefer closures, this is hardly a clusterfuck. But it would be fuglier in C/C++. [1] Yes, python has closures, which obey confusing rules and often work. But the pythonic way is an object handler.

lucian1900 15y ago
Python's closures are exactly like, say, scheme's, except that bindings are local by default.
- yummyfajitas 15y ago
  No, they aren't exactly the same: x = 0 def foo(): x = x + 1 print x UnboundLocalError: local variable 'x' referenced before assignment The javascript version works fine. var x = 0; var foo = function() { x = x + 1; console.log(x); } I realize there are ways around this, but they are considered unpythonic. For example: x = [0] def foo(): x[0] = x[0] + 1 print x[0] This works as you'd expect.
  - lucian1900 15y ago
    As I said, except that bindings are local by default. Python3's nonlocal allows explicit enabling of scheme-like behaviour.

LinaLauneBaer 15y ago

Animations were possible before blocks appeared. The non-block-based APIs is still around: -beginAnimations:context: -commitAnimations etc. The "completion" feature can be implemented via delegating. One thing to note here is: If you don't need the completion block you can also just write: myObj.position.x += 10.0 without blocks at all. At least on OS X every animatable object as an animator proxy that works like this: [myObj animator].position.x += 10.0; Then an implicit animation kicks in that can be configured. The default implicit animation duration is 0.25s but this can all the configured. The original Core Animation (without blocks) made working with animations so much easier and cooler. You could do everything you can do with the blocks API - although the blocks API is much nicer of course.