Re: const correctness
Re: const correctness
- Subject: Re: const correctness
- From: Luther Baker <email@hidden>
- Date: Sun, 18 Mar 2012 13:49:59 -0500
No no, you've both been very helpful. The time lines and "Mutable" thoughts
are great points and more than answer my underlying question.
Understanding a bit of the history goes along way when trying to
rationalize (and adhere to) current conventions.
Many Thanks!
-Luther
On Sun, Mar 18, 2012 at 1:39 PM, Jens Alfke <email@hidden> wrote:
>
> On Mar 18, 2012, at 11:01 AM, Luther Baker wrote:
>
> Obj-C and Cocoa don't support "const" because they are older?
>
>
> More because they weren’t designed around it. And because the way C++ does
> ‘const’ gets really problematic in a dynamic OOP language like Obj-C.
>
> Say you added ‘const’ object pointers to Obj-C. The direct meaning is that
> the caller isn’t allowed to modify instance variables through a const
> pointer. But touching another object’s ivars is almost unheard-of in Obj-C.
> So the significant meaning would be that the only methods you can call on
> such a pointer are those declared ‘const’; and inside a method declared
> ‘const’, ‘self’ is a const pointer, so the method isn’t allowed to modify
> instance variables. So far so good.
>
> The problem is how you declare a method as const. In Objective-C method
> names aren’t tightly bound to classes; they’re selectors and they exist
> independently. So different classes might implement methods with the same
> selector even though they aren’t related to each other, and you can send a
> message to an object using a particular selector without knowing what class
> of object it is (if the pointer is typed as ‘id’, or if you’re calling
> something like -performSelector:.)
>
> So things would start to get really messy if two unrelated classes
> implemented the same method name (i.e. same selector) but one made it const
> and one didn’t. Now if you send that message to an ‘id’ variable, the
> compiler doesn’t know whether it’s const or not and whether to allow or
> deny the call.
>
> Anyway. This is digressing, and probably belongs on the objc-language list
> if anyone wants to pursue it further. My guess is it isn’t worth pursuing,
> because Obj-C already has a different mechanism for handling mutable vs
> immutable state, and it works very differently (it’s the objects that are
> mutable/immutable, not just the pointers thereto), and trying to add in the
> C++ notion would probably be very ugly even if it could be done.
>
> —Jens
>
_______________________________________________
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