I think you've nailed it. Immutability is certainly a good concept, but including ideas from C++ is not a good idea because concepts are usually perverted in C++ (and even C - ALGOL carefully removed the junk out of FORTRAN and assembler but C, just put that garbage back in.) Concepts need very careful understanding of how they interact with the rest of a language before putting them in. With C pointers, you can just about subvert any good practice (even any good practice that got put in C++).
If people haven't seen this series, Douglas Crockford has a series on Javascript (ugh, I know, off topic..., don't tune out, please read on): http://net.tutsplus.com/tutorials/javascript-ajax/crockford-on-javascript-the-complete-series/ which is about far more than just Javascript. It is about why programmers are resistant to new ideas, how we usually end up with messes (JS in particular), language design, and subtly why C and C++ are poor languages. Oh, yeah, and why the web is such a mess (just bad ideas done quickly and a great perspective on the lasting effect of the browser wars). This series is well worth watching for the insights it has into our profession. Ian On 19 Mar 2012, at 05:39, Jens Alfke 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/ianjoyner%40me.com > > This email sent to ianjoy...@me.com _______________________________________________ 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
