If blocks are objects, how do they keep internal state and what are their advantages over regular objects?

Question

I was under the impression that blocks were supposed to resemble first-class functions and allow for lambda calc-style constructs. From a previous question however, I was told they are actually just objects.

Then I have 2 questions really:

1. Besides the feature of having access to their defining scope, which I guess makes them usable in a way resembling C++ "friendship", why would one go for a block instead of an object then? Are they more lightweight? Because if not I might as well keep passing objects as parameters instead of blocks.

2. Do blocks have a way of keeping an internal state? for instance, some variable declared inside the block which will retain its value across invocations.

Answer 1

Besides the feature of having access to their defining scope, which I guess makes them usable in a way resembling C++ "friendship", why would one go for a block instead of an object then?

Flexibility. Less to implement. A block is able to represent more than a parameter list or specific object type.

Are they more lightweight?

Not necessarily. Just consider them another tool in the toolbox, and use them where appropriate (or required).

Do blocks have a way of keeping an internal state? for instance, some variable declared inside the block which will retain its value across invocations.

Yes, they are able to perform reference counting as well as copy stack objects. That doesn't necessarily make them lighter-weight to use than an object representing the parameters you need.

Related

What's the difference between NSInvocation and block?

Answer 2

blocks were supposed to resemble first-class functions [...] they are actually just objects.

They are in fact first-class functions, implemented for the purposes of ObjC as objects. In plain-C, where they are also available, they have a closely-related but non-object-based implementation. You can think about them in whichever way is most convenient at the moment.

why would one go for a block instead of an object then?

A block is an executable chunk of code which automatically captures variables from its enclosing scope. The state and actions of a custom object have to be more explicitly handled, and are less generic; you can't use any old object as a completion argument, whereas an executable object fits that bill perfectly.

Do blocks have a way of keeping an internal state? for instance, some variable declared inside the block which will retain its value across invocations.

Sure, you can declare a static variable just like you could with a function or method:

void (^albatross)(void);
albatross = ^{
            static int notoriety;
            NSLog(@"%d", notoriety++);
        };

albatross();
albatross();
albatross();
albatross();