0

What would be the way to create a constant in objective-c that is called like a class property? (e.g. classA.KEY_FOR_ITEM1)

That is I see the advice re how to create a constant here http://stackoverflow.com/questions/538996/constants-in-objective-c This approach approach however seems to create a constant that is global and can be referenced anywhere.

I was more interested in a constant that you had to specify the context by using the class name too. So say you had an Event object, then you could have EventType constants specified (e.g. EVENTTYPE_DIRECT)

  EventType.EVENTTYPE_DIRECT

So the question is what would the *.h and *.m code segments be for this

Greg
  • 34,042
  • 79
  • 253
  • 454

2 Answers2

3

Sounds to me like you're coming from a Java-style language background, as do I (sorry if I'm guessing wrong here). I wondered about this too for a while, and then I noticed how Apple defines enums and uses them to define constants like you're describing.

Let's use the imaginary class Event as an example:

In the header file, you want to define a new enum:

typedef enum {

    kEventType_EventName1,
    kEventType_EventName2,
    kEventType_EventName3

}EventType;  //this is the name of the new type

where EventName1 etc, is replaced with the actual names of the events you want (ie. kEventType_Direct.

Any other class that needs to see these event types just needs to import your Event.h file:

#import "Event.h"

Then you can use EventType as you would any other variable type (bearing in mind that it is not an NSObject, and does cannot be retained, released, etc - you would treat it like any other C type: int, float, etc)

You can even have EventType typed variables as members of other classes, so long as those classes import your Event.h header.

But that allows you to do things like this:

-(void) handleEventOfType: (EventType) evtType {

    switch(evtType) {
        case kEventType_EventType1 :
            //stuff here
            break;

        //etc...

    }
}

That's the best way I've seen to do it so far, and seems to be the way that is generally practiced abroad (at least in most of the projects that I've seen). Anyway, hope that helps!

Ian
  • 3,806
  • 2
  • 20
  • 23
  • thanks that pretty much - so I guess re having to specify the class context first as in my example "EventType.EVENTTYPE_DIRECT" you can't really do this? but instead you work on the basis that it's at least not global as you do have to do the import first...oh and yep, you're pretty much right about being tainted with java previously :) – Greg Dec 04 '11 at 10:56
  • Yep, you've got it. I also wanted to get something pretty like ClassName.EVENT_TYPE and tried a few different things, but I couldn't get anything that didn't involve some ugly implementation. For C++ and Objective C, enums are the way to go :) – Ian Dec 04 '11 at 16:02
1

It's not clear what you are trying to do here - is the "constant" to be used to substitute for a property in the class, or is Class1.CONSTANT supposed to return a different value to Class2.CONSTANT?

Either way it seems like constants are not the right approach here. In the former case, simply use the real property accessor - if you decide to change this, the refactoring tools make that trivial.

In the latter case, each class could have a class method with your required name, which returns the value appropriate for the class. Again, if this changes the refactoring tools will help.

Adding constants to this mix seems unnecessary and introduces an extra dependency (the maintenance of the constants) without any real benefit.

jrturton
  • 118,105
  • 32
  • 252
  • 268
  • @jturton - it's kind of the latter - creating methods for each would do it, but I guess I was wondering if there was a simpler (quicker) way to do it that objective-c supports, noting the answer might be no. I just like the idea that a constant that really only applies the Event class, should have a means of having the Event class context required to be specified when using it...(e.g. EventType.EVENTTYPE_DIRECT)...so it's really just a readability thing I'd prefer to have in my code if it were possible. – Greg Dec 04 '11 at 11:03
  • Method names is the way to go then I think - this also gives you the benefits of code completion. Enums as suggested in the other answer are good too. – jrturton Dec 04 '11 at 11:27