Question

Why is it allowed to declare properties in categories when neither they nor their accessor methods are synthesized? Is there any performance overhead involved?

Is categorisation purely a compiler technique?

I'm trying to understand how categories work. This just explains what to do and what not to do. Are there any sources which go into more detail?

EDIT : I know that I can use associated references. Thats not what I'm asking for. I want to know why are the properties not synthesised? Is there a performance issue or a security issue if the compiler synthesises them? If there is I want to know what and how?

Was it helpful?

Solution

Why is it allowed to declare properties in categories [...] ?

Properties have many aspects (during compile- and runtime).

  1. They always declare one or two accessor methods on the class.
  2. They can change the selector when the compiler transforms dot notation to messages.
  3. In combination with the @synthesize directive (or by default) they can make the compiler synthesize accessor methods and optionally ivars.
  4. They add introspection information to the class which is available during runtime.

Most of these aspects are still useful when declaring properties in categories (or protocols) and synthesizing is not available.

Is categorisation purely a compiler technique?

No. Categories, as properties, have both compile time as well as runtime aspects.

Categories, for example, can be loaded from dynamic libraries at a later time. So there might already be instances of a class that suddenly gets new methods added. That's one of the reasons categories cannot add ivars, because old objects would be missing these ivars and how should the runtime tell if an object has been created before or after the category has been added.

OTHER TIPS

Before you go into categories, please reconsider the concept of properties in Obj-C: A property is something you can write and read to in an abstract sense, using accessors. Usually, there is an instance variable assigned to it, but there is no need to do so. A property may also be useful e.g., to set a number of different instance variables in a consistent way, or to read from severals variables or do some calulation.

The crucial fact here: there is no need to have an instance variable assigned to a property.

A category serves as an extensiton of an object's behavior, i.e., to extend its set of methods, without changing the data. If you see a property in it abstract sense, then it add accessors, thus it matches the idea of a category. But if you synthesize it, an instance variable would be generated what contradicts the idea of a category.

Thus, a property in a category makes only sense if you use it in the uncommon, abstract way, and @synthesize is to ease the common way.

You may want to read NSHipster about how to implement properties storage in categories.

Quoting from the article: "Why is this useful? It allows developers to add custom properties to existing classes in categories, which is an otherwise notable shortcoming for Objective-C."

@synthesize informs the compiler to go ahead and provide a default implementation for the setter and the getter.

Said default setters/getters rely on the existence of some kind of storage inside the object.

Categories do not offer any extra storage, so default setters/getters would have no place to store into, or read from.

An alternative is to use:

@dynamic

and then provide your own implementation and own storage for the said properties.

One way is to use associated objects. Another would be to store into/read from some completely unrelated place, such as some accessible dictionary of NSUserDefaults or ...

In some cases, for read only properties, you can also reconstruct/compute their values at runtime without any need to store them.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top