> As for the layer number issue, as I already said, you're free to search > and replace it to int. I'll do it personally if you like it.
Thank you for that offer. Since you were aware of my concern about LAYER_NUM ahead of your commit, and the fact that I do not view that enum as helpful, I will accept your offer, but only if I can convert you to my point of view. What is curious is that you never asked for why I hold my opinion. You simply sent me to a website, probably written by someone with a 1/3 of my C++ experience. I guess it is human nature, and we all do this as humans, to assume that if someone does not agree with us, that is their lack of information that is the cause. I am also guilty of this. But sometimes a question as simple as "why to you hold that opinion?" can yield very enlightening results. LAYER_NUM is mostly used as an iterator in our code, used to walk through for loops. What an enum brings is range safety. Used alone, it would only bring about a 1 in 28 layer chance of providing the proper value. This is your "type safety". "Type safety" is a comforting phrase, and even to the point of being misleading when used with enums. With enums it is essentially "fools gold", because it simply brackets a range of values. What would be real gold is "value accuracy". Value accuracy cannot be achieved by enums alone. "Value accuracy" comes from testing, unit tests, code maturity, asserts, proper limits on for loops, and other techniques. In our case code maturity and for loop limits play a key role. So for a 1 in 28 chance guarantee, then why is it to be weighed so heavily as to promoted as a solution to anything? It is *not* a solution to "value accuracy". If you like fools gold, and it makes you feel good, there may be some merit for it. For colors, the enum is not used quite as frequently as an iterator, so the downside is not as heavy. Then what is the downside you ask? The downside, or the cost, of using LAYER_NUM is that it becomes the center of attention of every for() loop. It makes the for() loop look non-standard, and makes opaque an iterator that really is nothing other than an index most of the time. In fact, nearly all the time. The upside is slim to none. The downside is only moderate. Hence my conclusion: "not helpful", after weighing the pros and the cons. The designers of Java go so sick of Microsoft's obfuscation of integer types, that they basically made it impossible to typedef an int. Their thinking is to be seen as revolutionary, and simplifying. Look at Java code, go back to the 80's and 90's and look at Microsoft Windows code examples. Java is simple and elegant by comparison. That is because in part, "int" does not become the center of attention in every for loop. The for loop limits, as I have said, are far more important to giving you "value accuracy". And int is more readable. > Then you're > even free to use void* for every pointer in the project. > Good luck then > finding when a layer is used instead of a simple counter (or something > which is not a layer is passed in, which actually occurred a few times > in the past). Also have fun with the two layer numbers encoded in > a single variable in the via class (obviously worth the 4 byte gain for > each via). > > Other than that these are only design opinions (altough type safety is > generally considered a good thing) and everybody can do whatever he want > with his own code. > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
