Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <ol> <li><p><em><strong>Is this appropriate use of the "by value" / "by reference" terminology?</em></strong> It's at least analogous to the typical use. Copying a value to a local variable is like copying a value onto the stack; using an ivar is like passing a pointer to a value that's stored somewhere else.</p></li> <li><p><em><strong>I do not see how self is being referenced in the "by reference" example?</em></strong> When you use an instance variable inside a method, the reference to <code>self</code> is implied. Some people actually write <code>self-&gt;foo</code> instead of <code>foo</code> to access an ivar just to remind themselves that <code>foo</code> is an ivar. I don't recommend that, but the point is that <code>foo</code> and <code>self-&gt;foo</code> mean the same thing. If you access an ivar inside a block, <code>self</code> will be retained in order to ensure that the ivar is preserved for the duration of the block.</p></li> <li><p><em><strong>Do you have any guidance on when one might want to do things one way or the other?</em></strong> It's useful to think in terms of the pass by reference/pass by value distinction here. As AliSoftware explained local variables are preserved when the block is created, just as parameters passed by value are copied when a function is called. An ivar is accessed through self just as a parameter passed by reference is accessed through a pointer, so its value isn't determined until you actually use it.</p></li> <li><p><em><strong>it seems like this is going to result in a lot of additional code for additional variable declarations?</em></strong> Blocks have been a feature of the language for a while now, and I haven't noticed that this is a problem. More often, you want the opposite behavior: a variable declared locally that you can modify within a block (or several blocks). The <code>__block</code> storage type makes that possible.</p></li> <li><p><em><strong>it seems like it may be more maintainable to avoid declaring the blocks inside of each other as one could ultimately end up with a potpourri of unintentionally retained objects?</em></strong> There's nothing wrong with letting one or more blocks retain an object for as long as they need it -- the object will be released just as soon as the blocks that use it terminate. This fits perfectly with the usual Objective-c manual memory management philosophy, where every object worries only about balancing its own retains. A better reason to avoid several layers of nested blocks is that that sort of code may be more difficult to understand than it needs to be.</p></li> </ol>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload