1

I have an Objective-C class that's intended for copy semantics.

 @property (copy) ViewState* viewState;

It’s not immutable, but everything that hangs on to a ViewState instance needs its own distinct copy. In fact, if some other class mistakenly tries

 @property (strong) ViewState* viewState;

we'll eventually crash.

How do we enforce or encourage client classes to use the correct semantics?

In C++, for example, we could prohibit assignment

 private:
 CPViewState* operator=(const CPViewState*) const;  // no implementation

But we can't do that in Objective-C. For the opposite case, where we want to prohibit copying, we can log an error or throw an exception from copyWithZone:.

How can I either require copy semantics or, at least, make it clear to future developers that they want to use copy semantics?

jscs
  • 63,694
  • 13
  • 151
  • 195
Mark Bernstein
  • 2,090
  • 18
  • 23
  • What do you mean by "if some other class mistakenly tries [...]"? Are you speaking about subclasses? – Ramy Al Zuhouri Jul 21 '13 at 15:37
  • MyWindow has a ViewState. Later, someone writes MyWindowManager which keeps track of the ViewState of each window and does other things. I want to be sure the author of MyWindowManager knows she ought to define her instance variable as @property(copy)... , not @property(strong). – Mark Bernstein Jul 21 '13 at 15:52
  • This kind of stuff can only be done modifying the compiler. It's enough if you write in the class documentation that instances should be copied and not assigned. – Ramy Al Zuhouri Jul 21 '13 at 16:00

1 Answers1

0

Copy semantics cannot be enforced from within the class itself, as you correctly explained.

Depending on where and how ViewState objects are created, and what that means conceptually, there are different things that could work.

I am not sure about what ViewState means in your project, but if it makes sense you could supply a singleton/factory ViewStateFactory class, which would have a few methods for creating and/or copying ViewState objects that clients would use. ViewStateFactory could then ensure that new copies are supplied every time a client requests a ViewState object.

Note that this is adds some boilerplate to the clients of your class. It also doesn't prevent people from going behind ViewStateFactory and directly allocating and/or referencing ViewState objects. But it could make more clear your intentions and how you want other people to use your class.

Ricardo Sanchez-Saez
  • 9,466
  • 8
  • 53
  • 92