Refering a static class

[K Viltersten]

I've placed all my constants in a class
called Donkey (since it's carrying all
the stuff). When i'm creating an array,
i get the info for the size from there.

int[] arr = new int[Donkey.FIX_VALUE];

Now, it's a little bit tedious and less
readable so i'd like to make "Donkey"
implicitly found.

After some laborating with "using" i've
gave up. How can i set up my Donkey so i
only need to go like this.

int[] arr = new int[FIX_VALUE];

I'm thinking of the same way as one can
get rid of the constant "System" in

System.Console.Write ("donkey");

by applying "using System;" and then
refering to the package right off.

Console.Write ("donkey");

Of course, it't not exactly equivalent
but i'm having hopes for it anyway.

 

[Peter Duniho]

I've placed all my constants in a class
called Donkey (since it's carrying all the stuff). When i'm creating an
array, i get the info for the size from there.

int[] arr = new int[Donkey.FIX_VALUE];

Now, it's a little bit tedious and less
readable so i'd like to make "Donkey"
implicitly found.

After some laborating with "using" i've
gave up. How can i set up my Donkey so i
only need to go like this.

int[] arr = new int[FIX_VALUE];

Other than declaring a member named "FIX_VALUE" in the class where you
want to use it, you don't.

Personally, I think this is a good thing. I already have mixed feelings
about the use of the "using" statement to alias types, but to remove the
type identifier altogether seems antithetical to some basic tenet of OOP..
Even in C++ where you could have global constants, it seems to me that
that's mainly a holdover from C as opposed to something that's a good idea
when you're actually writing real OOP code.

C# requires that your constants go into some class somewhere, and it also
requires that all references to any member of a class other than the one
in which the code doing the referencing exists be qualified to that
class. And I think this is a good thing. I know I'd hate to try to read
through code where I couldn't immediately tell the difference between
something that's defined within the class I'm looking at and something
that's defined elsewhere. That sort of flattening of the data structures
removes a large part of what makes OOP so useful from a code maintenance
point of view.

Besides, I think your idea of a class whose sole task is to hold constants
is a bit misguided. Every constant presumably has _some_ reason for
existing, based on some class that already exists. IMHO, that's where the
constant should be declared, rather than some catch-all place.

Conversely, if you have a constant that you _really_ believe _must_ be a
global constant and has _no_ other legitimate home, then if you find
yourself using that constant often enough that the few extra keystrokes is
a problem, you're misusing the constant. Most of your code should not
rely on constants; the values should be passed in from some early user of
the actual constant high up on the call stack or represented as some
property of a class instance. If you're typing the same constant name
over and over, that's a good sign that your code is not generalized
enough. Again, that's antithetical to the point of writing OO code.

Without seeing the full code and design, it's hard to say for sure. But
it sure sounds like you've got some basic design problem here that needs
fixing. Flattening your symbol space so you don't have the type the name
of the class holding a constant is most likely a poor bandaid for what's
really going wrong, whatever that happens to be.

Pete

 

[K Viltersten]

I've placed all my constants in a class

called Donkey (since it's carrying all the stuff). When i'm creating an
array, i get the info for the size from there.

int[] arr = new int[Donkey.FIX_VALUE];

Now, it's a little bit tedious and less
readable so i'd like to make "Donkey"
implicitly found.

After some laborating with "using" i've
gave up. How can i set up my Donkey so i
only need to go like this.

int[] arr = new int[FIX_VALUE];

Other than declaring a member named "FIX_VALUE"
in the class where you want to use it, you don't.

Thank you very much.

<snipping a long text of excellent comments>

I think you make an excellent argument. In fact, i've
already corrected a flaw in my design, thanks to your
suggestions.

However, one thing caught my attention. Are you for
pro or against using the syntax:

this.Info = null;

as opposed to

Info = null;

I'd go with "this" as this makes stuff very clear and
explicitly stated, if yet somewhat redundant. What
would you say?

 

[Christopher Van Kirk]

Chalk me up to the other camp. I think it's better to explicitly prefix
access to member variables with this. to differentiate them from locally
declared equivalents of the same name. I see alot of this going on in,
especially in constructors:


public class Foo
{
private int param1, param2, param3;

public Foo( int param1 )
{
this.param1 = param1;
}

public Foo( int param1, param2 )
{
this.param1 = param1;
this.param2 = param2;
}

...

public int DoSomeWork( int param1, int param2 )
{
int param3;

...
param3 = this.param1 / param1 + param2-this.param3;
}
}

Anyway, I picked up the practice from an ancient Microsoft coding guidelines
text, which I think they have since backed away from somewhat. I like it,
but its personal preference I guess.

[...]
However, one thing caught my attention. Are you for
pro or against using the syntax:

this.Info = null;

as opposed to

Info = null;

I'd go with "this" as this makes stuff very clear and
explicitly stated, if yet somewhat redundant. What would you say?

I generally do not explicitly write "this". After all, in C# there are no
global identifiers, and so without a qualifying reference, any identifier
must be relative to "this".

Sometimes you need "this". For example, a very simple class where instead
of properties you've made readonly public fields, and you want to use the
same name for constructor parameters as for the field names, you need
"this" to assign the parameters to the fields (I use that example
specifically because I think it's one of the few, if not the only,
situations in which it's not a bad idea for parameters to hide class
members).

But otherwise, I don't bother. Which is not to say that I object to code
that does explicitly use "this". If someone else wants to write it that
way, that's fine with me. I just think that in C# it's obvious enough
without it.

Pete