• 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: Convenience Methods
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Convenience Methods


  • Subject: Re: Convenience Methods
  • From: Jim Correia <email@hidden>
  • Date: Wed, 26 Sep 2007 08:22:55 -0400

On Sep 25, 2007, at 11:15 PM, Jeff Laing wrote:

But as far as inheritance contracts go out in OO land, I would *expect* that

[NSMutableString stringWithXXX: ...]

would return a *non*-mutable string since thats the contract that its
superclass establishes, and that NSMutableString does not redefine, at least
not that I can see.. Except that NSString does *not* establish that
contract

The object mutability guide mentions that <type>With<Type> methods are available for converting between mutable and immutable objects. But beyond the examples given, it doesn't enumerate them.


The problem here is with the 'isa' part of inheritance. The definition of
NSString is 'a datatype that cannot be edited'. How can NSMutableString be
a *subclass* of that definition?

When you are controlling the definitions, it is easy to set up a straw man then knock him down :-).


If you define an NSString as an object which is conceptually an array of unicode characters, and define NSMutableString as a subclass which extends the capabilities to include modifying the stored characters, it doesn't sound nearly as distasteful.

(I know what the current documentation says, and am I am ignoring it intentionally here.)

Early on, I wondered why 'const' never gets used in Objective-C. Presumably
because even an operation that would be const in other systems (adding it to
an array) results in the object itself having its retain count incremented
(which is an implementation detail of the array, not the object).

C++ has the mutable keyword so that you can, for example, alter the reference count in an otherwise const situation.


The mutable/immutable differentiation strikes me as a clumsy attempt to resolve
that problem, but it doesn't get there. In my opinion. Which may well
differ from yours.

It goes much deeper than applying a const modifier to say this method shall not mutate this object. (And that is ignoring the runtime dispatching of Objective-C.) It is saying that this object will not be mutated, ever, no matter what messages are sent to it. Sprinkling const here and there doesn't solve that problem, because anyone who gets a reference to your object *could* mutate it, if it were mutable.


The object mutability reference discusses some of the reasons why the Cocoa frameworks have mutable and immutable variants of objects.

This is not an uncommon approach which you'll find used in other domains (Java, Python, etc.)

Jim

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >RE: Convenience Methods (From: Jeff Laing <email@hidden>)

  • Prev by Date: Re: how to build finalcut-pro style gui apps?
  • Next by Date: Re: Convenience Methods
  • Previous by thread: Re: Convenience Methods
  • Next by thread: RE: Convenience Methods
  • Index(es):
    • Date
    • Thread