Use CamelCase syntax for all classes

[iMichka]

I would like to change the syntax of all the classes to use CamelCase, as this is how it should be for modern Python.

I started a pull request for this: https://github.com/gccxml/pygccxml/pull/89

Technically there is nothing really difficult here. There is just a choice to be made for our two main classes describing the different declarations and types: type_t and declaration_t. I was thinking renaming them to DeclarationD and TypeT. The D is for the declaration hierarchy, the T is for the type hierarchy. This would lead to (for example): EnumerationD and ShortIntT.

On reason is to have something in the name that easily allows to see to what class hierarchy the class belongs to. One another reason is that I can not have a Type class (type is a reserved keyword in Python. Type would be fine but I would like to avoid confusions between the lowercase/uppercase version).

I know that @RomanYakovenko @mamoll @MarkOates may have an opinion on this:

• should it be Declaration and Type, or DeclarationD and a TypeT + D or T suffix for all other classes
• Should we keep the old syntax around for the 2.0 release. I could do something like this: https://github.com/gccxml/pygccxml/pull/89/files#diff-f3ca1b6d15eb0878707ef50fcfa65c30R15 I was thinking about wrapping this with a deprecation warning, but I am worried performance could take a hit if a lit of warnings need to be printed ... so I would prefer to remove the old syntax for 2.0. If people want to keep the old syntax, they can stay on 1.9.0

[RomanYakovenko]

I saw the branch few weeks ago and frankly I don't know how to receive it or express gently my thoughts. pygccxml coding convention was born in order to make C++ developers feel comfortable with it. Not Python one, but C++. C++ developers was my main target. C++ has codding convention - std/boost libraries. For example - many names in "type traits" functionality are very similar/identical to C++. This is one point of view, another one current users. Why do you want to hurt them? Consider OMPL (https://github.com/gccxml/pygccxml/issues/56) py++/pygccxml performance issues. How many time/effort will be spent just to change the convention and for what? There are few project like it. For those projects investing time into "renaming" is a pure waste of time. Saying that, I understand your desire to make the package to be "Pythonic". I also understand that in open source & free project it is very important to enjoy from it. May be you need/want to consider to provide "py2to3" like conversion script. So the transition will be "semi/fully" automated. I will test such script on my projects.

Regards, Roman

[praetorian20]

FWIW, my thoughts are exactly the same as Roman's. I like that pygccxml has similar names as the C++ standard library where the functionality is also similar, and don't see a benefit in renaming.

My primary use of pygccxml is along with pyplusplus, so if you do the renaming, then the naming conventions will not match between the two libraries. I don't know if you have a lot of users using these two libraries together.

But you are the maintainer, so you're free to make the library naming convention more Pythonic if you choose to.

[mamoll]

I agree with @RomanYakovenko and @praetorian20. I was initially somewhat reluctant to complain, since I am hoping that @RomanYakovenko will eventually take over pyplusplus maintenance again, in which case the changes in my own projects that use pyplusplus would not be that painful.

[MarkOates]

Not sure how I got pinged on this but am very happy to provide my input. 🙂

Generally speaking, I am very much a supporter of classes being named with CamelCase (and feel that this should be a convention adopted across all languages), however, I don't think that naming convention applies here.

The elements in question are more types conceptually than classes. Types are conceived in the same way you would conceive int, float, std::string, int32_t, etc.

Generally, types like this are defined from smaller subtypes, but sometimes they can be made from more complex structs or classes. One reason a type definition might be more complex is so that it can more easily encapsulate the implementation of say, type conversions, operators, =, >, <, etc. And just skimming over the code, this seems to be what declaration_t is mostly made of.

In this sense, the existing naming convention is familiar to me and I see no reason to change it.

[iMichka]

Abandoning this idea for the moment. Got stuck with other projects, and I have not so much time anymore to take care of pygccxml. So I do not want to generate more work than needed.