Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><a href="http://developer.apple.com/library/mac/#releasenotes/Cocoa/RN-ObjectiveC/index.html" rel="nofollow noreferrer">Apple's documentation</a> explains this a bit, but here's a bit more detail…</p> <p>Instance variables that are declared under <code>@package</code> will only be accessible by code from the same framework, library or executable. This is most similar to <code>internal</code> in C# and <code>Friend</code> in VB.NET, but other programming languages have similar protections schemes as well (Java has <code>package-private</code>).</p> <p>For instance, imagine a framework, <code>RecipeKit.framework</code>, for managing recipes:</p> <pre><code>@interface Recipe : NSObject { @package; NSString *name; @private; NSArray *ingredients; } @end @interface RecipeController : NSObject @end </code></pre> <p>The recipe controller will be able to access the names of recipes directly. You would be able to write something like this in the <code>RecipeController</code> since it's part of the same framework:</p> <pre><code>Recipe *recipe = [[[Recipe alloc] init] autorelease]; [recipe-&gt;name autorelease]; recipe-&gt;name = [@"The best ever recipe!" retain]; </code></pre> <p>If you were to write the above code in an application linking to <code>RecipeKit</code>, though, it would cause a compiler error since you don't have access to that variable. Lastly, when compiled for 32-bit, variables declared under <code>@package</code> behave as if they were declared under <code>@public</code> instead, so watch out for the differences here.</p> <p>This new feature got very little attention because it's just one more way of breaking you're class's encapsulation. As has always been true, you're probably better off working with <code>@private</code> variables only and having accessor methods for them. In fact, for a while Apple was trying to push this by including <code>@private</code> in their templates. With properties in Objective-C 2.0, sticking with <code>@private</code> is easy enough, and depending on what platform you're targeting, you can <a href="https://stackoverflow.com/questions/4511700/synthesizing-a-property-without-instance-variables">leave out the instances variables entirely</a>.</p> <hr> <h3>Images</h3> <p>One thing that a few of the previous answers left a little unclear was addressing the aspect of images from the original question. In fact, the word image as used in the description of <code>@package</code> variables has nothing to do with graphical images. Instead it is referring to images that the dynamic linker is able to load. Generally executables, frameworks, and dynamic libraries are all considered images by the linker (though they are handled slightly differently). You'll see the word image pop up every once and a while. For instance, a common runtime error is: "dyld image not found". You'll also find the use of the word image scattered throughout documentation for <code>dyld</code>. Reading through the man page for <code>dyld</code> could help clear up the ambiguity of this word a bit. <code>UIImage</code> may declare variables as <code>@package</code>, but it has nothing to do with image as it pertains to the original question.</p>
 

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