Official Forum for Programming in Objective-C (the iPhone Programming Language) - Stephen Kochan
May 21, 2018, 09:40:44 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
   Home   Help Search Login Register Chat  
Pages: [1]   Go Down
Author Topic: Prog 10.3 question. What if I want to print 'january', 'february', etc...  (Read 1868 times)
Jr. Member
Posts: 53

« on: May 06, 2012, 09:20:51 PM »

Using Program 10.3, what if I want to print the monthname in the NSLog statement.

i.e. Number of days in _________ is 31.  where blank is the monthname, january, february, ... based on amonth value.

Is there a way to print the monthname (i.e. the value of the enum)?

I know I can create a string array of months, and use amonth as an index to print the corresponding month name, but is it possible to print the corresponding enum value using amonth?

Posts: 24

WWW Email
« Reply #1 on: May 17, 2012, 01:32:50 AM »

Hi rue! I was trying to do the same thing but I finally realized that it's impossible with amonth because those values are not like a key in a dictionary.
I have found the explanation below on
hope it will help you
Object Oriented Enums
Being built on C, Objective-C programs use traditional C style enums for a variety of purposes. However, there are a few problems with this approach:

They aren’t objects, so if you want to, for example, use them as a key in a dictionary, you have to wrap them up in an NSNumber instance
They aren’t extensible (without sacrificing type safety). You can’t have one enum inherit from another.
They are fragile - add a new enum anywhere other than at the end of the list, and watch all your old documents fail
They are difficult to log - while debuggers usually have enough symbol information to show symbolic enum values (assuming you have them stored in an enum typed variable, as opposed to a plain int), there’s no easy way to print that symbolic value.
They all live in the same namespace, so you can’t have two enum named “ON”, resulting in enum values that have long unique type information prefixing them.
One common approach that deals with some of these problems is to use constant NSString *. This solves several problems:
They are objects, so using them as keys in a dictionary is trivial
They aren’t fragile (so long as you don’t change their actual internal representation).
Trivial to log, since their value is a string that is (normally) a unique and descriptive value.
Unfortunately, you loose a few important features:
No longer type-safe - all constant strings are the same type.
Comparing can’t be done with a simple “==” test - an “isEqual:” message must be sent, slowing down the program, and making the source code wordier.
Still have namespace issues.

"The more i know people the more i love dogs."Socrate
Pages: [1]   Go Up
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Entire forum contents ゥ 2009 All rights reserved.