mikeash.com pyblog/friday-qa-2011-08-19-namespaced-constants-and-functions.html comments

Clay Bridges - 2011-12-09 20:28:11

Fri, 09 Dec 2011 20:28:11 GMT

I created a hack version of this for enum, and put the code on github (link below). I use a struct to mirror the enum, and use that to access the enum values using dot syntax. The include side would look like:



// your usual enum

typedef enum StoogeType {

    StoogeTypeMoe = 0,

    StoogeTypeLarry = 1,

    StoogeTypeCurly = 2

} StoogeType;



// a mirroring struct

struct StoogeStruct {

    StoogeType moe;

    StoogeType larry;

    StoogeType curly;

};



// how it gets accessed

extern const struct StoogeStruct StoogeTypes;

Then you could write something like



StoogeType stooge = StoogeTypes.moe;

Right now, it seems like a lot of work for little benefit, so I doubt the practical use, but ... good to know.

Link: https://github.com/claybridges/EnumDotSyntax

alexey - 2011-08-28 14:34:55

Sun, 28 Aug 2011 14:34:55 GMT

Wrong example, your forgot that notification should have full name to differ with other and a struct doesn't help with it.



    const struct MANotifyingArrayNotifications MANotifyingArrayNotifications = {

        .didAddObject = @"MANotifyingArrayDidAddObject",

        .didChangeObject = @"MANotifyingArrayDidChangeObject",

        .didRemoveObject = @"MANotifyingArrayDidRemoveObject",

        .keys = {

            .indexChanged = @"MANotifyingArrayIndexChanged",

            .objectChanged = @"MANotifyingArrayObjectChanged"

        }

};

And after that I think struct doesn't give any pros.

Jean-Daniel - 2011-08-28 08:48:45

Sun, 28 Aug 2011 08:48:45 GMT

I like this idea, but I see a little drawback.
When you add a new value in the header and you forget to add it in the implementation file, the compiler will no detect the error until runtime. If you use standard globals, the linker will tell you there is a missing symbol.

You may expect a "missing field initialization" warning in the struct definition, but unfortunately, using the c99 syntax inhibits such warning.

mikeash - 2011-08-27 02:21:13

Sat, 27 Aug 2011 02:21:13 GMT

It works fine in ARC, you just need to prefix any ObjC object members with __unsafe_unretained. Regarding GC, constant objects (the only kind you can put inside these structs) are not a problem.

Sean M - 2011-08-27 00:55:42

Sat, 27 Aug 2011 00:55:42 GMT

objects inside structs can be a problem for GC too, depending on wether the struct is allocated in scannable memory.

Andrey Mishanin - 2011-08-26 11:27:36

Fri, 26 Aug 2011 11:27:36 GMT

Mike, your solution is fine except for it won't interplay nicely with ARC since you're declaring objects inside a struct.

Lane Roathe - 2011-08-23 14:28:50

Tue, 23 Aug 2011 14:28:50 GMT

For what it's worth, Mike's solution is, at the most basic level, nearly identical to a namespace. ie:

    namespace MANotifyingArrayNotifications

    {

        NSString *didAddObject;

        NSString *didChangeObject;

    }



    MANotifyingArrayNotifications::didAddObject

is equivalent (more or less) to:

    struct MANotifyingArrayNotifications

    {

        NSString *didAddObject;

        NSString *didChangeObject;

    };



    MANotifyingArrayNotifications.didAddObject

Of course, namespaces are more flexible, but are not less (or more) prone to collision (ie, in either you can name an object at level X the same as another object at level X), although the flexibility of namespaces does make it easier to contain disparate items vs using a struct (ie, no need for a function to assign the values for instance).

mikeash - 2011-08-20 23:29:13

Sat, 20 Aug 2011 23:29:13 GMT

They would be a great solution if I could pull them in without getting any other C++ stuff, or if C++ were a real superset of C. :-)

Kentzo - 2011-08-20 22:20:12

Sat, 20 Aug 2011 22:20:12 GMT

I know you hate c++ Mike, but its namespaces are really good solution.

mikeash - 2011-08-20 17:19:04

Sat, 20 Aug 2011 17:19:04 GMT

I'm glad you enjoy the blog!

Regarding namespaced functions, I completely agree that writing classes is generally going to be a better approach. Namespaced functions aren't a replacement for classes, but rather a small improvement on regular C functions when used in this context. As you've no doubt noticed, C functions aren't very commonly used in Cocoa code. Where they *are* used, this technique could come in handy, but it's not going to happen very often.

If you wanted to go completely overboard, you could actually do a sort of namespaced class by putting a Class variable in a struct and then assigning it to a real class. But, probably not a good idea there.

Danny - 2011-08-20 03:16:02

Sat, 20 Aug 2011 03:16:02 GMT

First up, I love NSBlog. Been with ObjC for 5 months now and learned so much from this site. Thank you so very much for sharing.

As usual, this is another excellent post! Very intriguing. Now I want to refactor all my #defines and consts with namespaced constants! :) (Honestly, NSBlog is one of my main sources where I find inspirations/motivations for refactoring my code. I learn the techniques here and apply them to my code. It's the Friday I most look forward to :)

In regards to Namespaced Functions, I have a question for Mike and all you experts:

Although "namespaced functions" seem cool, I wonder if it's all that practical in the world of Cocoa. If I'm writing a project mostly in C (not taking advantage of the Cocoa framework), I can definitely see the benefit of namespaced functions. But if I'm writing an object-oriented solution, wouldn't it be better to simply write a wrapper class? Even though a class in ObjC doesn't give you the namespace notation, it offers so much more, especially when considering the principle of Separation of Concern? I guess my real question is: is there a scenario where I can use this technique (namespaced functions with struct) even in a project that's entirely composed in classes? Please enlighten me :) Thanks!

elliottcable - 2011-08-19 19:16:39

Fri, 19 Aug 2011 19:16:39 GMT

Yeah, when you demonstrate the idea tentatively, it gets called “really cool.”

When I do it in practice, and have been for years, I get called “insane,” “iditotic,” and other insulting intonations starting with “i.”

But, onto the subject; here’s quite a few examples of this applied in real-life:

My equivalent of a “header”: https://github.com/elliottcable/Paws.c/blob/323628/Source/Types/fork/LL.c#L33-63
The runtime initialization of the struct with the relevant functions: https://github.com/elliottcable/Paws.c/blob/323628/Source/Types/fork/LL.c#L83-127
Finally, the implementation of the functions themselves: https://github.com/elliottcable/Paws.c/blob/323628/Source/Types/fork/LL.c#L128-229

mikeash - 2011-08-19 16:30:47

Fri, 19 Aug 2011 16:30:47 GMT

Someone: I don't understand what you're getting at. Even with true namespaces, those can still collide if they have the same name too.

Someone - 2011-08-19 15:54:21

Fri, 19 Aug 2011 15:54:21 GMT

...but the whole point of a namespace is to prevent collisions. While the struct idea prevents collisions within itself, you still end up naming the struct itself. The name of the struct may collide.

Jamie - 2011-08-19 15:51:03

Fri, 19 Aug 2011 15:51:03 GMT

Unfortunately you still don't get the best part of namespaces, the resolution of unprefixed symbols.

Why Apple went to all the trouble of adding KVC dot-notation when they could have added namespaces I just don't know. I'm sure they had their reasons, but on Tiger I don't recall ever saying to myself "Gah I hate having to type 'objjctForKey:' over and over!" but I DO still say to myself "Gah what should I prefix my class names with on THIS project?"

Brian Mastenbrook - 2011-08-19 15:50:52

Fri, 19 Aug 2011 15:50:52 GMT

I have a #define for __attribute__ ((unused)) that I use on static consts.

Bill - 2011-08-19 15:37:51

Fri, 19 Aug 2011 15:37:51 GMT

But the namespaced constants trick with structs is really cool - thanks!

Bill - 2011-08-19 15:18:19

Fri, 19 Aug 2011 15:18:19 GMT

#define constants are only a problem in the debugger if you're stuck with Xcode. I use them quite happily in IntelliJ AppCode.

mikeash - 2011-08-19 15:04:07

Fri, 19 Aug 2011 15:04:07 GMT

Is there a way to use static const globals in your headers without getting warnings all over the place about them not being used in every single file where they're imported?

Brian Mastenbrook - 2011-08-19 14:46:32

Fri, 19 Aug 2011 14:46:32 GMT

Maybe I'm alone in this, but I tend to use static const for most of my constants. It's a good middle ground between preprocessor defines and extern const (which can't be constant folded by the compiler).

Regarding your crazy structs idea, I think it'd be a good idea to fold this kind of thing into the language. Maybe such a language could feature both an explicit namespace feature and an enhanced form of structs with inheritance, visibility control, etc. Someone should get on that!