Tom:

I’ll be sticking with attributes. It’s a cleaner, faster solution, period. Yours is very clever but not practical for commercial, high-performance, team-driven applications.

I think you missed some buzzwords there like ‘enterprise’.

Anyway, while I still don’t see how attributes are any faster (I’d like to see someone actually prove it with a benchmark), cleanliness is always a matter of personal taste, so more power to you. Maybe you should share the source code for a good attribute based alternative so people have an easy choice between both approaches? I’ll gladly link to it in the post.

Constant<float> having implicit conversions to/from float is not inherently bad in any particular way. There are always ways in which implicit conversions can trip you up, but they’re not guaranteed to cause issues. In this case, it is highly unlikely that an implicit conversion to/from Constant<float> is going to do anything bad: There will be no silent loss of data, and no silent execution of code. Furthermore, an accidental implicit conversion in this case is extremely unlikely.

I also don’t understand your assertion that this use of implicit conversions violates the strong typing of the language. There’s nothing soft or fuzzy going on here; the only remotely unclear thing is what happens when you assign a value like ‘9.3′ to a field of type Constant<float>. I would hope that even a junior programmer could quickly understand the meaning of such a statement.

The decision basically comes down to this: Do you want to manually write out ‘new Constant<float>(x)’ or just write ‘x’? If you choose the latter, you’re paying a cost by introducing some ‘magic’ (the implicit conversion) in order to reduce the amount of duplication within your codebase.

The suggestion that it could be a performance problem is a strange one. Of course everything has an implicit cost, but I find it highly unlikely that an implicit conversion from Constant<float> to float would ever show up on profiles. It’s definitely never shown up on mine.

The only real significant performance impact I can think of is that it eliminates the opportunity for the compiler/JIT to perform constant folding, which could be a real problem in high performance math loops. Even then, though, I’d have to see a significant overhead in profiles before I’d believe it.

At worst, you’re paying the cost of a method call and a read from memory to fetch the value – that’s it. And theoretically, the .NET JIT can inline the implicit conversion (They don’t ever guarantee that it *will*, but the documentation says it can.)

The attributes still don’t seem any smaller than my approach to me. C# attribute syntax is too noisy for it to be a win on size. The fact that the attributes are decoupled from the rest of the declaration is potentially a win, I suppose, but I’ve never needed that.

Being able to use #if to make a constant not a constant anymore doesn’t seem particularly useful for me. I can’t think of a possible use case for this where it wouldn’t result in tremendous duplication. Of course, you can do this with my approach too – just #if/#else out the type part of the declaration – but I can’t imagine a good reason to do that either.

Saying you don’t need IConstant or ConstantManager suggests that you missed the purpose of those classes: Those are there specifically to enable simple, type-safe manipulation of your constants. There’s no way to magically get that functionality for free; it has to come from somewhere.

I also find your assertion that attribute reflection is faster to be dubious. Do you have any data to support this? Finding fields by attribute isn’t any faster than finding them by type as I understand it, since in both cases you have to enumerate defined types and then enumerate their fields in order to check each field for its attributes. Is there a helper ’search’ method somewhere in the Framework that performs this search for you more efficiently when aimed at custom attributes?

The suggestion that this approach ’spits in the face of OOP’ confuses me. I don’t understand. I wanted to be able to modify constants, so I created an object to represent a modifiable constant. I don’t see how this is inherently less pure OO than using an attribute.

I’m also not sure what ‘pro world’ you refer to in which techniques like this don’t fly. I’ve seen far worse techniques ship in commercial codebases. In the end, the determination is up to the people working on the app, and hopefully they make their choices based on what actually works, not based on fear or rhetoric. If this solution didn’t solve my problems, I wouldn’t be using it.

You initialize you classes just like I would initialize my attributes. You do them with an operator overload, which, most veteran programmers would say is very bad practice. Implicit conversion operators are sloppy at best and bad OOP practice as it blurs the lines of ‘Strongly Typed Language’. Non the less, we both are instantiating something with ONE line of code. So far, we are equal.

My attribute class is smaller than your constant class:

[AttributeUsage(AttributeTargets.Property)]
public class EditableUiProperty : Attribute
{
public EditableUiProperty (string name) { this.name = name; }
string name;
}

Mine is 4 lines of code and has less members. So, now at this point, i’m using less code than you’re “ICONSTANT” or “CONSTANT” implementation. Also, if another developer looked at this, they wouldn’t even need to ask me what’s going on, it just makes sense and is clearly readable when it’s used……

[EditableUiProperty("Boss")]
public float BossPunchDamage = 8;

Now, i have no need for “IConstant” or the “ConstantManager “. So i don’t even code those.

So now, at this point, i’m using way less code.

We both use reflection, but since mine is based on attributes, my reflection actually performs faster, instead of looking for instances of objects and finding them by type, like you do.

In both approaches, we could choose to pull out this implementation so there is no sign of it in our production code.

Just like you said “when you’re done tweaking, you can trivially pull them back out”

You are not actually ‘pulling anything out’. You are changing the TYPE of these members to a value type when it was previously a reference type. If you do performance tests before you pull out all YOUR implementation, the results will be different after you go back, and change all those ‘constants’ to value types.

In mine, i can do this…..

#if DEBUG
[assembly: AssemblyConfiguration("Debug")]
#endif
float BossPunchDamage

Wow! Now i don’t need to touch my code. No going back and changing a ton of stuff. I just put my project into ‘Release Build’ mode and those attributes no longer exist. It’s impossible to do that with your approach.

In mine, all the ‘constants’ stay the same type. It’s less obtrusive. My performance tests would be practically the same before and after.

Remember, every time your code reads one of these values for the game logic, YOUR code does the implicit type conversion. This spits in the face of OOP and strongly typed programming and is a performance drop when you multiply it by 1000.

On to XML parsing. If you don’t know how to pull values from XML in a few short lines, and wrap that into a reusable utility function, there are plenty of resources online. That’s hardly as complicated as using StackFrame to actually change source code.

Another benefit of my approach, is, you can write your ‘variable editor application’ separate from your game, and actually perform these edits using only the assembly of your game, instead of all the source code. I know that defeats the purpose of this article, but i think it’s a cleaner approach.

In all, you say it’s a taste thing, but i don’t think it’s that subjective. When you are coding in by yourself, then sure, nothing matters, but in pro world, this kind of stuff doesn’t fly.

I know you are sharing a cool thing you did, and i don’t want to shoot you down for that. Any time a programmer takes the time to share thoughts online, it’s a privilege for all of us. However, i think of the junior developers that might come across this and think this is totally great solution. So this is why i provide contrary evidence. And hey, who’s to say anyone will read this far down anyway (ha!).

That’s my rant. I like some of the other articles on your site, and you’re not a bad programmer. Keep up the good work.

There’s no real performance benefit; I’m not sure I ever suggested there was one. The point of this approach is to avoid having to repeat yourself and only need to make minimal changes to your code (essentially, you replace ‘const x y’ with ‘Constant y’, which you can trivially do with a regex) in order to enable tweaking values. And when you’re done tweaking, you can trivially pull them back out.

Ultimately it all comes down to taste, though. Using attributes to tag things and saving/loading from a file was an approach I considered initially; I ended up going with this approach after reading about a similar one implemented in C using macros, just to see how it worked out.

Another option in the xWinForms library. It’s almost ALL the controls from real WinForms, re-coded from scratch to work in XNA.

Because it’s re-coded from scratch, It’s buggy as hell, but i have personally implemented it and works cool. Luckily, the source code is provided, as i needed to change several things in their code. Still an awesome effort that deserves a look.

http://www.gameprojects.com/project/?id=e68f3464c4

It’s neat but i think you completely over complicated something, and in the process, mangled symantics.

What you have there are certainly not constants. I don’t mean to nitpick, but in C# constant is a real word that has a very specific meaning.

What you have are regular read only properties. What is the performance benefit to using this approach? None. You aim to create a solution to globally find all ‘constants’ so you can edit them in your UI. In most cases, while you are tweaking things, you don’t need access to ALL constants in the assembly at once, and if your game has quite a lot, then you end up with a bloated UI and have to scroll forever to find your one property (in alphebeical order i assume).

Your solution has no way to group these constants.

.NET made something for you that is much better than your approach. They are called attributes. Decorate your VARIABLES with custom attributes,

[CustomGameConstantAttribute("BigBadEnemyBoss")]
private READONLY float BossPunchDamageAmount { get; set; }

Now, using a little reflection, you find ALL properties that have the ‘CustomGameConstantAttribute’. Better yet, you group them by the argument value and your UI can only load the ‘constants’ for the ‘bigBadEnemyBoss’. You’re UI could have a cool drop down list at the top so you can choose what group of ‘constants’ you want to edit.

So now, you have an easy way to get to your constants.

Even better, when it’s time to ship your game, you simply remove the code that does the actual reflection, and what you have left are properties with attributes that are ignored….. no performance cost what so ever.

Your approach leaves artifacts of your ‘development process’ in your game code.

In the actual running game, is there any reason to have those properties be your ‘Constant’ type? Of course not. It’s only needed to make it easy to edit while developing. So why make it part of the running game’s architecture?

Also, your approach to writing your values back to the actual source code is dangerous. Code generation is cool, but this is not a good case study of it. Since these are NOT constants, write to XML, and populate the values at runtime. Your approach already throws the benefit of constants out the window. You can populate a static variable at runtime, no big deal. They can still be READ ONLY if you populate them inside the constructor.

Those are my two cents. Of course, i’m a college drop out, and maybe i missed your point, but i just layed out how i would solve your problem in less time, with less code, and no impact on the production code i ship to my customers while using preexisting mechanisms of .net.

Of course, i will assume you would not be doing this on XBOX, so this solution would only work on windows.

I don’t mean this to sound like a scathing attack. If i didn’t care, i wouldn’t write anything. Any maybe you can tear me a new one and i’ll learn something.

Happy Coding