Re: const correctness
Re: const correctness
- Subject: Re: const correctness
- From: Ian Joyner <email@hidden>
- Date: Mon, 19 Mar 2012 22:51:53 +1100
On 19 Mar 2012, at 09:31, Shawn Bakhtiar wrote:
> "...subtly why C and C++ are poor languages..."
>
> 1) Is that why most modern operating systems, especially the ones that run in data centers are written in C?
>
Popularity is more a proof of mass stupidity rather than quality. The cult of C followed on from what Bob Barton called the cult of FORTRAN in 1963 and also noted that systems programmers are high priests of a low cult.
> 2) Isn't Objective-"C" a supper set of C, so does that make Objective-C a bad language as well?
Unfortunately OC is C-based, but it changed C in a completely different way to C++ in a way that OC is almost a decent language, in fact the best dialect of C that exists.
>
> Isn't Mutability just another word for constant-ability?
No, that's immutability. C it's already confusing talking about things in see :-)
>
> I hate to use Wiki for citation but:
>
> http://en.wikipedia.org/wiki/Const-correctness
>
> "In computer science, const-correctness is the form of program correctness that deals with the proper declaration of objects as mutable or immutable. The term is mostly used in a C or C++ context, and takes its name from the const keyword in those languages."
Well, it's more instructive to follow the link to immutable objects.
>
> Doesn't const void ** = NSMutableArray in meaning,
Actually NSArray. Note NSMutableArray inherits from NSArray because it adds extra functionality in methods that can change the object. You can assign an NSMutableArray object to an NSArray reference, thereby making it unchangeable via that path, but you can't assign an NSArray object to an NSMutableArray.
> with the first being a simple way for the programmer to avoid clobbering data that SHOULD not be changed, and the latter being a compiler enforced one?
Well, const void ** (what gobbledegook, let me get my head around it), means you cannot change the pointed to objects (haven't they got the message C pointers are bad) via that pointer. An NSArray reference to an NSArray object means you can't change that object, ever vs., an NSArray reference (note references are different to pointers) to an NSMutableArray means you can't change the NSMutableArray via that reference. As already said you can't have an NSMutableArray reference to an NSArray object.
Still suggest watching Crockford where he traces C's ancestry to ALGOL with the junk from FORTRAN and assembler put back in, the junk the ALGOL people (many of whom had previously designed FORTRAN, like Backus) had deliberately left out. An extension of ALGOL then brought us OO – Simula. Crockford also advises on how to avoid the bad parts of JavaScript, a lesson we need in avoiding the bad parts of C. C has more to do with assembler programming than HLL and structured programming. You don't need assembler to write operating systems - I'd hardly call them modern. (The only truly modern OS I can think of actually predates them all.)
>
>
>
>
>> Subject: Re: const correctness
>> From: email@hidden
>> Date: Mon, 19 Mar 2012 09:16:52 +1100
>> To: email@hidden
>>
>> 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 (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
>>
>>
>> _______________________________________________
>>
>> 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
>
> _______________________________________________
>
> 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
_______________________________________________
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