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 <j...@mooseyard.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
