• 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: Know about Mutability
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Know about Mutability


  • Subject: Re: Know about Mutability
  • From: glenn andreas <email@hidden>
  • Date: Fri, 14 Jan 2005 12:38:51 -0600


On Jan 14, 2005, at 12:22 PM, Prachi Gauriar wrote:


On Jan 14, 2005, at 12:22 PM, Shawn Erickson wrote:

The problem is that the setting of this flag isn't cleanly or easily exposed by the traditions methods like isKindOf, respondsToSelector, etc. at this time. Apple could address this in various ways with various levels of potential backwards compatibility issues (depending on quirks / assumptions in existing code). It may be best to provide a universal isMutable method on NSObject (or course that has backwards compatibility issues with any one that has added such a method via a category ect.) that can be used to understand in one shot if an object is or isn't mutable.

It seems to me that they should just override isKindOf:, respondsToSelector:, etc. in NSCFDictionary to take the flag into consideration. At some point, backwards compatibility is going to have to be given up so that these methods behave as documented. We shouldn't have to know about the internal implementation of NSDictionary... they should just modify the internals so that the standard inspection methods behave normally.


Just my 2 cents.


I'm curious under what cases do you really need to know if you have a mutable object or not? If a method definition says mutable, it's mutable, and if not, you better code with the idea that it's immutable.


If you need to make a change to something, and it's immutable, you've got design problems (because at that point you'll need to make a mutable copy anyway, and so you are no longer referring to the original object anymore anyway, so any changes you make will be to the local copy which will be lost).

The only good case where this makes sense is in writing bridges to other languages/runtimes which have different mutability models, such as the PyObjC bridge (between Objective-C and Python). In those cases, you may change a mutable list into a python list, and an immutable list into a python tuple. In general, though, these "convert from one model to another" are fairly rare.

But if your routine changes the value of a parameter being passed into it that's declared as not mutable (or you mess with a return value that's declared as not mutable), they you are violating the "contract" you've got with your caller (or other method), resulting in something which is far more likely to run into strange and hard to track down bugs.


Glenn Andreas                      email@hidden  <http://www.gandreas.com/> oh my! Mad, Bad, and Dangerous to Know

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Know about Mutability (From: James Bucanek <email@hidden>)
 >Re: Know about Mutability (From: mmalcolm crawford <email@hidden>)
 >Re: Know about Mutability (From: Andrew Pinski <email@hidden>)
 >Re: Know about Mutability (From: mmalcolm crawford <email@hidden>)
 >Re: Know about Mutability (From: Hugh Hoover <email@hidden>)
 >Re: Know about Mutability (From: Peter Maurer <email@hidden>)
 >Re: Know about Mutability (From: Paul Sargent <email@hidden>)
 >Re: Know about Mutability (From: Shawn Erickson <email@hidden>)
 >Re: Know about Mutability (From: Prachi Gauriar <email@hidden>)

  • Prev by Date: Best way to convert audio to other formats?
  • Next by Date: Document Loaded From File
  • Previous by thread: Re: Know about Mutability
  • Next by thread: Re: Know about Mutability
  • Index(es):
    • Date
    • Thread