• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mutable classes and class clusters
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mutable classes and class clusters


  • Subject: Re: Mutable classes and class clusters
  • From: John Hörnkvist <email@hidden>
  • Date: Sat, 15 Sep 2001 22:20:47 +0200

On Saturday, September 15, 2001, at 09:48 PM, Rob Rix wrote:

1) What benefits do separate immutable and mutable classes provide? I'm developing a framework, and I'm wondering whether I should separate the mutable aspects of some of my classes into a mutable subclass.
It occurs to me that the rationale behind this decision might have been the fact that NSArray et al are class clusters. Is this the case?

The point is that it allows you to tell the user of a class that "I will not modify this (argument) object", or "You may not modify this object" and so forth.

Consider something like;
- (NSArray*)windows;
versus
- (NSMutableArray*)windows;

In the first, you're handed an array which you're not allowed to change. In the second, the type is telling you that you can change it.

If you find yourself in a situation where you often make copies of an object before returning it, or passing it as an argument, then a mutable/immutable class is useful.

2) One of the classes I'm implementing in my framework is about to be redesigned as a class cluster, with a single public class (unless I find that separating it into mutable and immutable would be worthwhile, of course). So, to make a class cluster, is all that is involved changing my class' -(id)init method so that it returns an instance of a private subclass?

Essentially. Don't forget to collect any garbage in the init method, though.

You may also want to handle serialization; otherwise you can become locked in with a certain implementation. "replacementObjectForCoder:" should be helpful, there.

Should I also have said private subclasses report that they are actually members of the superclass when queried with things like -isMemberOfClass, -class, and +class?

I can't see any good reasons for doing that.

Regards,
John Hornkvist
--
ToastedMarshmallow, the perfect Cocoa companion
http://www.toastedmarshmallow.com


  • Follow-Ups:
    • Re: Mutable classes and class clusters
      • From: Rob Rix <email@hidden>
References: 
 >Mutable classes and class clusters (From: Rob Rix <email@hidden>)

  • Prev by Date: Re: Objective-Fortran
  • Next by Date: Re: Mutable classes and class clusters
  • Previous by thread: Mutable classes and class clusters
  • Next by thread: Re: Mutable classes and class clusters
  • Index(es):
    • Date
    • Thread