Inconsistent Terminology


#1

I noticed there is varying terminology meaning essentially the same thing.

Identifier::null //Which isn't const, and probably should be const, by the way!

ValueTree::invalid

Why the deviation for ValueTree? Isn't an Identifier invalid when it's "null" (tough it's not really null; it's an empty string), or a ValueTree null at its core when invalid?

It's almost like these would be better represented this way; from the perspective of their root member object.

Identifier::empty
ValueTree::null

Though, for consistency;

Identifier::null
ValueTree::null

#2

Well.. these classes have different uses, I don't think there's really a single naming convention that would work for all of them. I called it ValueTree::invalid because you can't actually do anything with an unnamed ValueTree, so it's more for use as an error case rather than being a useful object. Likewise, Identifier::null isn't an empty string, it's actually an invalid value, so if anything it could be renamed Identifier::invalid. Calling it Identifier::empty would give the wrong sense of its purpose IMHO.

TBH there are potential problems with static initialisation of all these things - if you use any of them inside code that's called directly or indirectly from a static initialiser, then you run the risk that the compiler won't have created it yet. For that reason (as well as avoiding worrying about their names!) I no longer use them in my code, but always use ValueTree(), Identifier() etc. instead.

...and although I've not tested this, I have a hunch that if you're returning e.g. a null ValueTree from a function, then "return ValueTreee();" is probably going to be optimised better by the compiler than "return ValueTree::invalid;" would be.


#3

Or in C++11 you can

​return {};

for a defaultly constructed object. ;)


#4

Cute.