public static final Naming Conventions

[Stevens Miller]

If I want something to do the job of a C-style #defined constant, I use this:

public static final int MAX_PLAYERS = 4;

I'm writing some JNI code that must respect constants defined in C header files. Rather than mirror them in my code (which runs the risk that Microsoft or whomever will change it on the C side, leaving me with a mismatch on the Java side), I've created a native routine that returns the constant. I call that from my class's static method, so it can define a final variable, so that variable can go on to serve the same purpose as if it had been assigned a value as above:

public static final int MAX_PLAYERS;

private static native int getMaxPlayers();

static
{
    System.load.("C:\\users\\smiller\\game.dll");

    MAX_PLAYERS = getMaxPlayers();
}

This works fine and I'm happy with it (unless someone has a better way). But, there are some values that are not constants on the C side, even though I am assuming they will remain constant for a single run of my application. For those, I have been coding thusly:

public static final int MAX_PLAYERS;
public static final int numberOfJoysticks;

private static native int getMaxPlayers();
private static native int getNumberOfJoysticks();

static
{
    System.load.("C:\\users\\smiller\\game.dll");

    MAX_PLAYERS = getMaxPlayers();
    numberOfJoysticks = getNumberOfJoysticks();
}

This also works, but NetBeans grouses at me that a, "Constant name does not follow naming conventions." According to NetBeans, a constant should always match the regex, ([A-Z][A-Z\d]*_?)*[A-Z\d]+. For compile-time constants, I agree. But for values that cannot be known until run time, does that still hold?

Thoughts?

[Stephan van Hulst]

Values that are not known until runtime simply are not constants. A constant has a fixed value, and will theoretically never change (unless we have a better way of measuring them, in which case their value will be 'corrected').

numberOfJoysticks is not constant, and therefore should not be static. Make it a instance field, and assign it in the constructor. You can then load the value like so:

final class ApplicationThatUsesJoysticks {

  private static native int getNumberOfJoysticks();

  public static void main(String... args) {
    int numberOfJoysticks = getNumberOfJoysticks();
    Game game = new Game(numberOfJoysticks);
  }
}

[Junilu Lacar]

I would ask:

1. Does it make code that uses it misleading or confusing to read?
2. What kind of problems would confusion lead to?
3. What do you plan to do to address the confusion that would be caused?
4. Is the path to resolution of confusion intuitive or easy to find/follow?
5. Are other developers fine with this?
6. Do you really care that much about NetBeans grousing?

[Junilu Lacar]

Of course, to Stephan's point, "Is it really a constant?"

[Daniel Cox]

Stephan van Hulst wrote:Values that are not known until runtime simply are not constants.

I guess an enum constant is an exception. Its identity is unknown until runtime but it is regarded as a constant since its identity stays constant at runtime.

[Stephan van Hulst]

Enums are not exceptions. MyEnum.SOME_VALUE should ALWAYS equal MyEnum.SOME_VALUE, even if you've serialized the constant in one run and deserialized it in a later run.

[Daniel Cox]

By exception, I was referring to your statement "Values that are not known until runtime simply are not constants". An enum constant's "value" (identity) is not known until runtime but it is regarded as a constant since it stays constant at runtime.

[Stephan van Hulst]

package com.example.constants;

import java.io.*;
import java.nio.file.*;

import static java.nio.file.StandardOpenOption.*;

enum Color {
  
  RED, GREEN, BLUE;
  
  public static void main(String... args) throws Exception {
    Path path = Paths.get("green.color");
    
    if (!Files.exists(path)) {
      System.out.println("Writing GREEN to file.");
      
      try (
        ObjectOutputStream output = new ObjectOutputStream(
          Files.newOutputStream(path, CREATE_NEW, WRITE, TRUNCATE_EXISTING)
        );
      ) {
        output.writeObject(GREEN);
        System.out.println("Done writing.");
      }
    }
    
    else {
      System.out.println("Reading a color from file.");
      
      try (
        ObjectInputStream input = new ObjectInputStream(
          Files.newInputStream(path, READ)
        );
      ) {
        Color color = (Color) input.readObject();
        
        // We even use identity comparison!
        if (color != GREEN)
          throw new IOException("Somebody tampered with the file!");
        
        System.out.println("It is GREEN, duh!");
      }
    }
  }
}

First run:

Writing GREEN to file.
Done writing.

Second run:

Reading a color from file.
It is GREEN, duh!

[Stephan van Hulst]

Daniel Cox wrote:By exception, I was referring to your statement "Values that are not known until runtime simply are not constants". An enum constant's "value" (identity) is not known until runtime but it is regarded as a constant since it stays constant at runtime.

If by 'identity' you mean the constant's memory location, then my answer is that the memory location doesn't matter.

For instance, here's another example of what I regard as a constant:

final class ChessPosition {

  /**
   * Even if A1 may have a different memory location between runs, conceptually its VALUE is always constant.
   * A1 will ALWAYS be equal to A1.
   */
  static final ChessPosition A1 = new ChessPosition('a', 1);

  private final char file;
  private final int  rank;

  ChessPosition(char file, int rank) {
    if (
      file < 'a' || file > 'h' ||
      rank <  1  || rank >  8
    ) {
      throw new IllegalArgumentException();
    }

    this.file = file;
    this.rank = rank;
  }

  char file() {
    return file;
  }

  int rank() {
    return rank;
  }

  @Override
  public boolean equals(Object obj) {
    if (!(obj instanceof ChessPosition))
      return false;

    ChessPosition other = (ChessPosition) obj;

    return this.file == other.file
        && this.rank == other.rank;
  }

  @Override
  public int hashCode() {
    return 8 * (rank - 1) + (file - 'a');
  }

  @Override
  public String toString() {
    return "" + file + rank;
  }
}

[Bear Bibeault]

Meh. To me, values that are set at the outset of the run from a configuration (or some such) and are never changed are "constants". And I name them as such.

Yeah, technically, they're not. But from the point of view of code clarity, they are.

E.g.

  private static final String ACCESS_KEY = Play.configuration.getProperty("storm-report-service.service-param-accessKey");

[Campbell Ritchie]

Bear Bibeault wrote:. . . values that are set at the outset of the run . . . and are never changed are "constants". . . .

Agree with Bear.

[Daniel Cox]

Maybe my knowledge of enum constants is flawed. If values that are not known until runtime are not constants, then why is an enum constant regarded as a constant when its value is not known until runtime but stays constant at runtime.

enum WeekDays {
    MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY;
}

The value of the enum constant WeekDays.MONDAY is "MONDAY" and this value stays constant at runtime.

[Stephan van Hulst]

Who says their value isn't known? The value of MONDAY is MONDAY. The value of TUESDAY is TUESDAY, and so on. The value of 1 is 1 and the value of Math.PI is Math.PI. All of these are constants.

I'm of the opinion that values instantiated from resource files can be treated as constants, they're effectively part of your program. Values read from user editable configuration files are not constant, even if you don't change them during the course of a program run. Treating them as constant is dangerous, because it may cause unit tests to behave non-deterministically.

[Daniel Cox]

Stephan van Hulst wrote:Who says their value isn't known?

I don't think that an enum constant is technically a compile-time constant which to me implies that its value is not known at compile-time.

Bear Bibeault wrote:...values that are set at the outset of the run...and are never changed are "constants"...

I think that's another example of a "constant" that is not known at compile time but is regarded as a "constant" - the object referenced by ACCESS_KEY is not known at compile time.

[Stephan van Hulst]

Daniel Cox wrote:I don't think that an enum constant is technically a compile-time constant which to me implies that its value is not known at compile-time.

They are though. For instance, you can use them as cases in a switch statement.

[Junilu Lacar]

Interesting digression(?)... so does this mean that nobody really gives a hoot about Netbeans' grousing about naming conventions for constants vs non-constants?

[Daniel Cox]

Now I'm confused. In this thread, Chan Ag asked if enum constants are compile time constants and the general response is that they are not.

[Daniel Cox]

In that thread, Campbell Ritchie says

One cannot ∴ say that enum elements are implicitly constants.

[Campbell Ritchie]

The definitive authority is the Java® Language Specification (=JLS), and that section doesn't say anything about compile‑time constants. They are called constant expressions, even though 99.99% of programmers call them compile‑time constants. You will find that constant expressions may be of type String or one of the eight primitives. So there is no general agreement here, only what the JLS says.
Although the elements of an enum are called constants, and can be used after switch ... case, they do not count as constant expressions. You cannot use them for any of th operations specified in the first JLS link. You can say
2.0 * Math.PI
which is one of the examples in the JLS, but you cannot say things like
2.0 * Days.SUNDAY

Anyway, enum constants don't count as constant expressions and the JLS can be very difficult to understand.

[Daniel Cox]

Campbell Ritchie wrote:Anyway, enum constants don't count as constant expressions...

Makes sense to me since enum constants are objects and objects are not created at compile-time. I presume they are regarded as "constants" because their value is guaranteed to stay constant at runtime.

[Stevens Miller]

Junilu Lacar wrote:so does this mean that nobody really gives a hoot about Netbeans' grousing about naming conventions for constants vs non-constants?

I'm hooting about it to the extent that, as I have the humility of a saint, I tend to start by assuming any grousing from NetBeans about my code is probably well-founded grousing or, at least, sufficient reason to investigate what it is grousing about. In a lot of cases, that's how I've found my way to better practices.

[Junilu Lacar]

So my question then would be how much has the discussion on this thread helped you on this quest for better practices? Personally, I don't really pay much attention to half the things analyzers complain about. It's those warnings about things that can be misleading to the reader or make it more likely for a bug to be introduced that I'll watch for. I'm on the fence with this one though, hence the questions I suggested. While the subsequent discussion about compile-time constants and the JLS is somewhat interesting to follow, it seems a bit too academic to me, frankly. I would be more concerned about the answers to those questions I posed and what it all means to other developers.

[Stephan van Hulst]

Stevens, one of the things that occurred to me earlier this evening was that NetBeans doesn't necessarily grouse about using all caps for constants: Java's naming convention is to use all caps for variables that are static and final. You can adhere to that convention rather easily, no matter if you or we think of them as constants or not.

There have been several people who've given their opinion about what they consider constants. None of us really are a definite authority. It's up to you now to determine what you feel comfortable with.

[Stephan van Hulst]

Junilu Lacar wrote:so does this mean that nobody really gives a hoot about Netbeans' grousing about naming conventions for constants vs non-constants?

I care about my tools' warnings up to the point where I think I know better.

I'm very intimate with NetBeans. There are many warnings that are enabled by default that I disable, and there are many warnings that I enable that are disabled by default.

A tool is a tool. You use them to the capacity you deem them useful.

[Paul Clapham]

I know in Eclipse there's a page where you can configure all of those nagging warnings as "Error", "Warning", or "Ignore". Whether Netbeans has this option, I don't know.

[Junilu Lacar]

I agree with your last point, Stephan. I just wanted to bring the discussion back to focusing on Steven's question rather than the semantics of constants per the JLS.

[Stephan van Hulst]

In that case, my final answer is that Stevens' variables should be capitalized solely because they're static and final, regardless of whether you or I or he or the language developers had a clear idea about what a constant is, because static final variables are supposed to be capitalized as per Java's conventions. The discussion whether it's a constant is unrelated.

NetBeans makes this more confusing because they refer to it as a constant, but they probably mean that it's a static and final variable.

[Stephan van Hulst]

Paul Clapham wrote:I know in Eclipse there's a page where you can configure all of those nagging warnings as "Error", "Warning", or "Ignore". Whether Netbeans has this option, I don't know.

Yes, NetBeans has something similar. I would be surprised there was an IDE where this was not the case.

[Junilu Lacar]

I'd have to agree with Stephan, Stevens. On trying to answer my own questions before, I concluded that the all caps constant name convention would be more meaningful to me as another developer who had to read and/or maintain the code. There's a Stroop-esque effect when the name doesn't follow the normal convention and the cognitive dissonance is just something I'd rather avoid.

[Winston Gutkowski]

Daniel Cox wrote:Makes sense to me since enum constants are objects and objects are not created at compile-time.

They aren't? What about String literals?

Enums are a bit of an odd bird, since they look like (and presumably are) objects, but several things about them suggest that they're static; just one being that you can do things like:

...
   VALUE1 {
      public int someMethod() {
        // implementation
      }
   }
   VALUE2 (
      public int someMethod() {
         return VALUE1.someMethod();
      }
   }
   ...

and you can even forward-reference them. This suggests to me that they could be created at comple-time; but whether they actually are or not I have no idea (and TBH, I don't really care).

Winston

[Winston Gutkowski]

Stephan van Hulst wrote:...NetBeans doesn't necessarily grouse about using all caps for constants: Java's naming convention is to use all caps for variables that are static and final.

Hmmm. I can't honestly think of a situation where I'd want a static field that isn't final. In fact, if I was writing an IDE, I'd certainly make that a warning.

Winston

[Campbell Ritchie]

Winston Gutkowski wrote:. . . Enums are a bit of an odd bird, since they look like (and probably are) objects, but several things about them suggest that they're static; . . .

To the BatMobile JLS!

That LS link §8.9.3 wrote:For each enum constant c declared in the body of the declaration of E, E has an implicitly declared public static final field of type E that has the same name as c. The field has a variable initializer consisting of c, and is annotated by the same annotations as c.

That means that an enum contant is a static final field of its class and is also an instance of that class, named as the enum. If it is an instance, then it is an object in its own right. You can also call Object methods on it and do some reflection:-

public class EnumSuperclassDemo
{
    private enum Things
    {
        OBJECT, ARTICLE, ITEM;
    }
    
    public static void main(String... args)
    {
        printSuperclasses();
    }
    
    private static void printSuperclasses()
    {
        Class<?> clazz = Things.OBJECT.getClass();
        System.out.println(clazz.getName());
        do
        {
            clazz = clazz.getSuperclass();
            System.out.println(clazz.getName());
        } while (clazz != Object.class);
    }
}
/*
 * output:
 * java EnumSuperclassDemo
 * EnumSuperclassDemo$Things
 * java.lang.Enum
 * java.lang.Object
 */

You can also tell the enum is a static member of that class because it is not called on an object reference.

[Daniel Cox]

Winston Gutkowski wrote:

Daniel Cox wrote:Makes sense to me since enum constants are objects and objects are not created at compile-time.

They aren't? What about String literals?

For whatever reason, the compiler doesn't treat enum constants the same way it treats String literals which is why enum constants are not compile-time constants. I think that String literals are a special case. Nevertheless, whatever the compiler does to String literals at compile-time, the String objects are not created at compile-time according to this article. They are created by the JVM when a class is loaded.

When a .java file is compiled into a .class file, any String literals are noted in a special way, just as all constants are. When a class is loaded (note that loading happens prior to initialization), the JVM goes through the code for the class and looks for String literals. When it finds one, it checks to see if an equivalent String is already referenced from the heap. If not, it creates a String instance on the heap and stores a reference to that object in the constant table.

[Stevens Miller]

To Junilu's question, yes, this discussion is most helpful. See, the important thing when making an implementation decision is the ability to defend it at the code review. As an attorney, I know that cases are won in preparation, so we have an answer ready to any possible challenge. This discussion has exposed points of attack for various options, and provided rebuttals to those attacks sufficient to withstand the majority of criticisms that are likely to be levied in a group context, where, under the pretext of collectively seeking a better overall result, each of us is individually hoping to reveal the incompetence of our colleagues. Having snappy rejoinders to the pernicious critiques of one's co-workers can be what it takes to leave you the last one standing.

Of course, except for you guys, I work alone, so I have the luxury of actually being able to make my choices on what I think really will work best. In this case, I'm still a bit puzzled, but not because the advice here hasn't been good. It has! But some of it has made me realize I need to study the proper use of statics a bit more. Part of my problem is that I am, on this project, merely implementing a set of wrappers for a Windows API, one that was written to be called by C/C++, and not with any attention given to OO concepts. It's full of #defines, pointers to structures with members that are changed by the functions that take them as parameters, and other Microsoftisms that don't all naturally seem to map into Java paradigms.

One point made here that is worth mulling is that a "constant" seems to be something the IDE designers got to define for themselves. "The Elements of Java Style" uses that word to (as others do) refer to something modified with public static final, and it seems that's pretty common parlance. But, it's not precise. For example, which line in the code below do you think makes NetBeans grouse, and why?

enum Cons
{
    ONE
}

class Vars
{
    static final int TWO = 2;
    static final int THREE;
    
    static
    {
        THREE = 3;
    }
}

public class Main
{
    static final String FOUR = "4";
        
    public static void main(String... args)
    {
        switch(Cons.ONE)
        {
        case ONE:
        }
        
        switch(2)
        {
        case Vars.TWO:
        }
         
        switch(3)
        {
        case Vars.THREE:
        }
        
        switch("4")
        {
        case FOUR:
        }
    }
}

[Junilu Lacar]

My guess would be that static initialization block, specifically line 13 (or line 35). Why? I couldn't guess NetBeans' stated reason for grousing but the root cause would be a shortcoming(?) in its style checking rules in accounting for this scenario.

[Stevens Miller]

Junilu Lacar wrote:My guess would be that static initialization block, specifically line 13 (or line 35). Why? I couldn't guess NetBeans' stated reason for grousing but the root cause would be a shortcoming(?) in its style checking rules in accounting for this scenario.

You are very close, and props for not cheating by just loading it into NetBeans. The complaint (which is actually a genuine compile-time error, not just the opinion of someone at NetBeans High Command) is at Line 36, "Constant expression required." This gets downright funny when you force NetBeans to grouse again by changing the name of Vars.THREE to Vars.three, which again has it complaining that, "Constant name does not follow naming conventions." So NetBeans thinks it's a constant for naming purposes, but not for purposes requiring a constant expression (and the compiler agrees with that latter view). Assigning a value to a variable that is static final in a class's static method is allowed, and that's what got me into this quandary in the first place: it allows for the value of a final to be set at run time, rather than at compile time. I like that, because I am querying a Windows API for its constants and this method avoids my having to maintain a parallel set of definitions (which might not remain parallel, if Microsoft ever changed one of them). For all such values that are set at compile time on the Windows side, the ALL_CAPS format feels right. But there are values that are not defined on the Windows side at compile time, but that I am treating as fixed for one run of the program.

For example, I am using the Windows XInput API, which reads the family of Xbox 360 controllers. You can have, at most, four of them connected to your PC at one time. That number is available via the #defined value, XUSER_MAX_COUNT (that, btw, is a good example of a "constant" that might change, as Microsoft might someday decide to support more than the current limit of four). However, you might not have four controllers connected. A game's maximum number of players might be limited by that number but, for a given run of the game program, the run is going to be limited to the number of controllers you have. When the program starts, it can count them, and that gets reported back by my C++ JNI code to Java in the call to the static getNumberOfJoysticks method. Now, Stephan suggested that I not treat that as a static, but as a member variable. I'm not sure I see the advantage to that. My technique has the combined virtues(?) of marking the value final, while allowing it to change from one run of the program to another. But, like I said, Stephan and Winston (among others) have raised some doubts in me about how well I really understand the use of static variables (they do that to me all the time, too... it gets depressing ). Most likely, I am misusing my statics in some way that reflects my continuing inability to shuck off the vestiges of my procedural coding style.

Hard to learn new tricks when you're an old dog, but I'll keep trying.

[Junilu Lacar]

Stevens Miller wrote:Stephan and Winston (among others) have raised some doubts in me about how well I really understand the use of static variables (they do that to me all the time, too... it gets depressing ). Most likely, I am misusing my statics in some way that reflects my continuing inability to shuck off the vestiges of my procedural coding style.

This is kind of why I asked whether the deeply technical discussion was actually useful. While the discussion is informative, my focus would be on semantics from a client point-of-view rather than on the esoteric inner workings of the compiler, which are implementation details that I'd rather not have to care much about. Stephan and Winston have indicated a bottomline leaning in the same direction. [Winston: "and TBH, I don't really care", Stephan's first response in this thread].

One question I ask myself often, especially after learning to think in terms of TDD, is "What if I flip all this on it's head and approach it from the opposite direction?" Looking back at your code, I have to question the choice to expose MAX_PLAYERS rather than something like getNumberOfJoysticks(). Do you really want that value globally exposed? Does it need to be? Would it make more sense to have a Game impose that limit internally?

It seems to me that Stephan's suggestion would be the way to go, or something similar to this:

public class GameFactory {

    private static native int getNumberOfJoysticks();

    static {
         System.load.("C:\\users\\smiller\\game.dll");
    }

    public static Game newInstance() {
         return new Game(getNumberOfJoysticks());
    }
}

So, if Game knows what the maximum number of players would be based on the number of joysticks currently attached, what kind of API would be ideal on Game, based solely on known usage scenarios?  Does a Game client really need to use a Game.MAX_PLAYERS constant? Would that even make sense (thinking in OO)?  Is there a way steer to the "conversation" with Game in a different direction, where we don't need to know MAX_PLAYERS? What would the design look like?

[Junilu Lacar]

BTW, the implementation of Game in the above context would be something like:

package ...; // same one as GameFactory

public class Game {
    private final int maxPlayers;

    // package private constructor, for use by GameFactory
    Game(int maxPlayers) {
        ...
    }
    ...
}

As another developer, I would be able to discern immediately what the parameter to the constructor means. The capitalization or lack thereof of the maxPlayers member and its designation as private final also tells me a lot about its usage and intent. If I go to the GameFactory.newInstance() method, I would immediately realize that the value passed to the Game constructor is based on what's returned by the native method call to find the number of physical devices attached. For me, these would be the appropriate abstractions to take, hiding implementation details as deeply as possible while still maintaining clarity of purpose and intent.

[Stevens Miller]

Junilu Lacar wrote:Looking back at your code, I have to question the choice to expose MAX_PLAYERS rather than something like getNumberOfJoysticks(). Do you really want that value globally exposed? Does it need to be?

You're good. For most applications, I think driving the constants down as deep (and as far away from the rest of the code) as possible is usually the way to go, presenting only the logical abstractions that are truly relevant at the high levels. If, at run time, a game can only provide participation for as many players as there are joysticks, then access to MAX_PLAYERS would be kind of useless, whereas getNumberOfJoysticks() might be highly pertinent.

I deliberately tried to make the question a bit more abstract than it actually is in my real-world situation (because I wanted to focus on the general case, not the details of my particular problem). In my real-world situation, I am writing Java wrappers for the XInput API functions. These let you gain access to Xbox 360 controllers connected to your PC. Owing to some quirk that governs how the controllers are given their identifying numbers, you can't just ask the API for access to the first one, then the second one. Rather, you must poll all possible controllers and find out which index numbers will give you access to a connected device. To do that, you have to know what the maximum number of them could be, and that number is #defined in XUSER_MAX_COUNT (it is four, btw). Thus, to find your controllers, you need a loop like this:

for(int i = 0; i < JavaXInput.XUSER_MAX_COUNT; ++i)
{
    if (JavaXInput.XInputGetState(i, state) == JavaXInput.ERROR_SUCCESS)
    {
        // Construct a controller here for the one on index i.
    }
}

I've already observed that Microsoft is giving it to us straight on this. That is, a single controller plugged into my computer sometimes appears on index 1, not always on 0. According to their documentation, the index can even change for the same physical device, if you plug it into a different USB port. So, to find all the controllers you have available at run time, you simply have to poll all possibilities, which you means you need to know the upper limit. Would a person writing a game need that? Probably not, if I write these wrappers correctly. But I'm not writing a game, I'm writing something to be used by someone who will be writing a game. At the game level, access to JavaXInput.XUSER_MAX_COUNT can be made unnecessary. At the level of my wrappers, I believe I need it.

BTW, the return code indicating that a controller is present really is called, by Microsoft, "ERROR_SUCCESS." I believe it is things like this that explain why, eventually, all computer programmers go mad.

[Winston Gutkowski]

Stevens Miller wrote:I deliberately tried to make the question a bit more abstract than it actually is [...] In my real-world situation, I am writing Java wrappers for the XInput API functions...

Actually, I think it is an abstract problem, and I agree completely with Junilu that you should be concerning yourself with the semantics of that problem, and not bits and bytes - in my (I'm sure by now, nauseating) terminology: the "what", not the "how".

Forget what a constant means to Java for the moment. What is it to YOU and your application?

To my mind a constant is something that is set at creation time and cannot be changed - ie, it either doesn't exist, or it has a fixed value - which further suggests to me that, whatever it is, it's immutable.

It does, however, have scope. A static final field in a class, or an Enum instance, is likely to "live" for as long as the JVM that loads it exists; but a final field in a class will live for as long as its associated object does. I'd categorise both as constants; just at different levels - and of course, with different naming conventions.

Now it's possible that whatever "value" (or values) that your constant represents may need to be loaded from an outside source, but that doesn't change what it IS intrinsically, it's simply part of its implementation.

I hope I haven't missed the gist of this thread, but my worry is that you're getting bogged down in XBox implementation details, rather than working out what the word "constant" means in the context of YOUR application.

HIH

Winston