2

I'm not sure if this is the right place to ask this, since it's not really a technical question but more a question of style and coding practices...

I've always ben a fan of using "const" to define variables that will not be changing throughout their lifetime, most especially when they are parameters to functions/methods. This probably stems from my history with C++, where objects could be passed by reference rather than by pointer, but you wanted to ensure that the original value wasn't accidentally altered, either by you or by someone else on your team who was working on the same code snippet.

When looking through the headers for both Objective-C in general and Cocos2d specifically, I've noticed that there is a noticeable lack of use of this item. Now, I'm not against developing code as quickly as possible, and leaving off constraints such as these leave the developer the option to modify values as their code develops and evolves, but there are some instances where I believe that this laxity does not belong.

For example, in Cocos2D/UIKit, the "UIFont fontWithName" method takes "(NSString *)" as the parameter for the font name: does this method really need to reserve the right to alter the original string that was passed in? I personally like to define constant strings as "const" items, and I don't like the necessity of casting these as non-"const" when calling these methods.

Enough proselytizing: My question - Is the direction now moving towards less well-defined interfaces and more towards "lazy references" (which I do not consider to be a derogative term)?

Thanks in advance for any feedback....

miwalsh
  • 111
  • 2
  • 9
  • 2
    ObjC is not C++. `NSString` is immutable. It is not possible to modify it (with public interface). For mutable class, they are normally called `NSMutableXXX` e.g. `NSMutableString` – Bryan Chen Jul 25 '14 at 05:37
  • Thanks, Bryan, I know that as well, it wasn't a question about Swift, it was a question about why "UIFont fontWithName", for example, takes "(NSString *)" instead of "(NSString const *)" as the name of the font; the current method **implies** that the invoked method is free to modify the buffer passed in as it sees fit. – miwalsh Jul 25 '14 at 05:40
  • @miwalsh `(NSString *)` is the datatype of parameter. Why you want a const in parameter datatype? – Yogesh Suthar Jul 25 '14 at 05:42
  • I was just asking a question of style, Bryan, not looking for an argument, sorry if it came across that way.... – miwalsh Jul 25 '14 at 05:43
  • 1
    @Yogesh Please see the conversation with Neal below, that may explain more clearly what I was talking about... – miwalsh Jul 25 '14 at 05:57
  • The `const` is a lie! http://stackoverflow.com/a/11036371/201863 – CodeSmile Jul 25 '14 at 06:07

1 Answers1

4

Const wouldn't mean anything for Objective C class pointers, because it would have to be overloaded in a very confusing way for Objective C types. This is because there's no way to mark a method as const, as there is in C++, so the compiler could never enforce it.

That said, at my old company, we did declare global string constants using something like:

NSString* const kMyCoolString = @"Hello, world!";

The point being that it at least couldn't be reassigned to something else.

The closest analog in Objective C/Cocoa/Foundation are mutable/immutable versions of data structures, which doesn't really help your case.

neal
  • 557
  • 2
  • 9
  • thank you Neal, that is exactly how I am defining things in my code now; I was just wondering if there is a reason that this clarification of specifying "NSString const *" instead of "NSString *" (I know, not a good example, but one nonetheless) to tell users of this interface that there will be no changes made to parameters passed to methods was no longer in use. – miwalsh Jul 25 '14 at 05:48
  • 1
    I don't think const was ever meant solely as an indication to the programmer or consumers of an interface. It was meant for the programmer to instruct the compiler to check for unintended changes to the object/variable. Such unintended changes can't be prevented with Objective-C today so const wouldn't help anything. – neal Jul 25 '14 at 05:50
  • 1
    I agree, but the language **does** support the old C structure definitions, which can be passed by pointer reference to methods, and "const" should still be a guarantee that the called method will not change the contents of the given data element. Do you agree? – miwalsh Jul 25 '14 at 05:53
  • 2
    It makes sense to use const as you would in C for C structures. It does not make sense to define const values for objective-c objects as such const objects may still be mutated and non-const values may be immutable. For obj-c objects let the type enforce mutability. – Jonah Jul 25 '14 at 05:56
  • @Jonah Thanks, Jonah... I work on multiple projects consecutively, in multiple programming languages, specifically Objective-C, C++, and C, switching mental gears as I move from project to project, and I was just wondering at this general lack-of-use of a fairly pervasive construct. Again, thanks! – miwalsh Jul 25 '14 at 06:00
  • @miwalsh I would agree that if you are using C structs or C++ objects and having them const as method parameters was appropriate, you should definitely do it. But now I'm a bit confused as I thought your question was about Objective-C types. (I'm not sure if you know this, so apologies if you do, but Objective-C classes/objects are implemented with a completely different runtime - methods are invoked via a message passing mechanism at runtime, and not dynamic dispatch or a jump to a known code location) – neal Jul 25 '14 at 13:51
  • @neal Hey Neal, "yes", I do understand that, but one of the great features of Objective-C is that it allows you to mix-and-match the new paradigm with the old ( if you are careful :) ), which, as a developer, allows me to re-use certain logical constructs that I've built in the past with little or no changes required. – miwalsh Jul 25 '14 at 13:56