Another thought, cocos is another shorter and readable namespace.
Usually all classes are in 2d. There is no meaning to have suffix 2d
cocos::Sprite
cocos::Layer
cocos::Node
Later if there exist 3d classes, there should be another sub-namespace
cocos::3d::Node
Later if there exist 3d classes, there should be another sub-namespace
cocos::3d::Node
Interesting. Thanks.
I think it is safe to keep using cocos2d as namespace. If in the future we add 3d components, we could review the namespace name. We could create a namespace alias, or something like that.
BTW: IIRC, the namespace in cocos2d-python is cocos.
+1 for cocos::Sprite
My n00b Cocos user (but very experienced programmer) opinion is:
Hi,
I like to remove CCSprite and make it Sprite.
BUT, I don’t see why we need to move the namespace from cocos2d to CC:
I like readable code, even if I have to type 5 additional keys 
Hi, CCSprite —> Sprite, Good.
but cocos2d —> cc, I don’t think so. “cc” can be anything.
cc most famously being the “C compiler”.
(gcc is the “GNU C compiler” later renamed “GNU compiler collection”.)
Hi,
Riq spending whole time in development of cocos2d-x 3.0 is really a great news.
However regarding changing namespace and moving to c++ conventions, I do see one small issue. So far there aren’t many books (aware about recent releases) & tutorials about cocos2d-x.
However, given that cocos2d-x is based on cocos2d, any available cocos2d reference material usually applies (with no or minimal changes) in cocos2d-x without much confusion, even if its done by a fresher. Of course, with growing community support,documentation and recent release of books, this won’t be there for long time, but as of now there is good chunk of material which is for cocos2d, not specific to cocos2d-x. And that works great because both framework shares same structure.
So if such basic items will change, it might make things a bit hard specially for one who are new to mobile development or cocos2d-x.
Hi,
I pulled the last git commits and the transition to the new name policy is huge for projects using cocos2d-x. And it is a bit frustrating What do you think about including a transition header with macros that would make the thing easier ? For instance
#ifdef CC_OLD_NAMESPACE_TRANSITION
#define CCNode Node
#define CCSprite Sprite
...
#endif
If it is ok to you, I can do that and propose a pull request. What do you think ?
But macros can’t mark them as deprecated class. Or is there a way to warn developers that he used a deprecated class name?
Éloi Rivard wrote:
Hi,
I pulled the last git commits and the transition to the new name policy is huge for projects using cocos2d-x. And it is a bit frustratingWhat do you think about including a transition header with macros that would make the thing easier ? For instance
[…]
>
If it is ok to you, I can do that and propose a pull request. What do you think ?
Well that’s why there is a “#ifdef CC_OLD_NAMESPACE_TRANSITION”, developers that want to use those macros for transition acknowledge that those macros are old ones and wont be supported a long time.
We can set a compiler warning to when those macros for example.
@Éloi Rivard
We can set a compiler warning to when those macros for example.
Could you shared more informations about this?
How to set a compiler warning when developers use old name, like CCSprite, CCNode?
This seems to be actually the better solution:
typedef Sprite CCSprite __attribute__ ((deprecated));
typedef Node CCNode __attribute__ ((deprecated));
This emits a -Wdeprecated-declarations warning
Cool, I will test it. If it works, I’ll add it to CCDeprecated.h. Thanks.
Éloi Rivard wrote:
This seems to be actually the better solution:
>
[…]
>
This emits a -Wdeprecated-declarations warning
Fixed at https://github.com/cocos2d/cocos2d-x/pull/3185 .
Éloi Rivard wrote:
This seems to be actually the better solution:
>
[…]
>
This emits a -Wdeprecated-declarations warning
This is great !
I notice that there is no CCDeprecated.h in extensions. Do you think it is a good idea to keep (and deprecate) CC prefix compatibility with extensions too ?
Yep, Extension also needs this header file. I’ll add it too.
Éloi Rivard wrote:
This is great !
I notice that there is no CCDeprecated.h in extensions. Do you think it is a good idea to keep (and deprecate) CC prefix compatibility with extensions too ?
I’m pretty much a cocos2d-x noob with some cocos-iPhone experience and an aweful lot of other (non game) programming experience…
Removing the CC prefix, to me, makes it more difficult to see at a glance whether the class I am looking at is a Cocos class or some other class - so personally I’d vote in favour of keeping the prefix even though it is strictly speaking unnecessary.
Regarding the namespace - I think cocos would be ideal; cc is a little too short and (if you keep the CC prefix) will rarely need to be used outside the ‘using’.
Max Young wrote:
Removing the CC prefix, to me, makes it more difficult to see at a glance whether the class I am looking at is a Cocos class or some other class - so personally I’d vote in favour of keeping the prefix even though it is strictly speaking unnecessary.
This need to go away, it’s a objective-c thing, not a C++ one. If you need to know where the class comes from use the namespace to show it.
Regarding the namespace - I think cocos would be ideal; cc is a little too short and (if you keep the CC prefix) will rarely need to be used outside the ‘using’.
If you want to put it everywhere (like some people do with std: cc:: is perfect.
Right now i have some cocos2d::extension::CCScrollView declarations in my code and they look awful. cc::extension::CCScrollView is way better.
We could also use a shorter name for cc::extension, don’t you think?