Readonly kind of variable declared somewhere by defined somewhere else?

[John Dalberg]

I would like to declare variables that can't be modified (like readonly)
however I want to declare them in a single class so I can always refer to
the same class whenever code uses them. However I want to give them values
in constructors in different classes in different files.

What's the best way to accomplish this functionality?

John Dalberg

 

[VJ]

I still don't fully understand what you are trying accomplish.. its tough to
give efficient OO ideas without a requirement picture. But from what you
say..using static variables in public class is a option. I generally don't
like to use static variables a lot, so if you are thinking of a lot of
variables, then a sketch of requirement picture might help people here to
give better idea.

VJ

 

[John Dalberg]

I still don't fully understand what you are trying accomplish.. its tough
to give efficient OO ideas without a requirement picture. But from what
you say..using static variables in public class is a option. I generally
don't like to use static variables a lot, so if you are thinking of a lot
of variables, then a sketch of requirement picture might help people here
to give better idea.

I want to do something like this:

class static MyConstants
{
public readonly Name1;
public readonly Name2;
}


class A
{
A()
{
MyConstants.Name1 = "Some name";
}
}


class B
{
B()
{
MyConstants.Name2 = "Some name";
}
}

The idea is to consolidate all non modifiable variable in one class but
give them an initial values in other classes.

John Dalberg

 

[Jon Skeet [C# MVP]]

The idea is to consolidate all non modifiable variable in one class but
give them an initial values in other classes.

That sounds like a bad idea to me. Do the variables have anything in
common other than being read-only? It doesn't sound like it.

Constants (and the like) are best expressed in their related classes -
so we have int.MaxValue and double.MaxValue, not Constants.MaxInt32 and
Constants.MaxDouble etc.

 

[VJ]

Singleton Pattern will help here?

VJ

That sounds like a bad idea to me. Do the variables have anything in
common other than being read-only? It doesn't sound like it.

Constants (and the like) are best expressed in their related classes -
so we have int.MaxValue and double.MaxValue, not Constants.MaxInt32 and
Constants.MaxDouble etc.

 

[VJ]

Ok my bad.. no singleton.. coffee time of the day...Sorry

Anyways what John is doing seems to be ok.. why is it bad to keep
application wide constants in a common class?

 

[Jon Skeet [C# MVP]]

Ok my bad.. no singleton.. coffee time of the day...Sorry

Anyways what John is doing seems to be ok.. why is it bad to keep
application wide constants in a common class?

Because all they have in common is that they're constants. If they were
all configuration parameters, then it would make sense to keep them in
a Configuration class, because that describes their purpose. However,
"constant" describes one particular attribute of the value, rather than
what the purpose of the value is.

I mean, it'll *work*, but it doesn't scale well as the project scales
up - you end up having to use very long names because part of the name
describes the general area of the constant, which would be a good
candidate for a class in which to put the constant.

 

[John Dalberg]

Because all they have in common is that they're constants. If they were
all configuration parameters, then it would make sense to keep them in
a Configuration class, because that describes their purpose. However,
"constant" describes one particular attribute of the value, rather than
what the purpose of the value is.

They are like configuration variables but their values are determined
during runtime.

I mean, it'll *work*, but it doesn't scale well as the project scales
up - you end up having to use very long names because part of the name
describes the general area of the constant, which would be a good
candidate for a class in which to put the constant.

Scaling is not an issue because the app is not going to get big. Why is
long names an issue? The number of variables will not exceed 50. Don't
names convert to some random short names in IL regardless of how long the
name was in the code?

You said they are a good candidate to be in a class. Isn't that the same
what I was proposing? I want all these va riables in be in a custom class
so that I can refer to them using a single class name with the help of
intellisense instead of remembering which class contains them if they are
going to be scattered in different classes.

John Dalberg

 

[Jon Skeet [C# MVP]]

They are like configuration variables but their values are determined
during runtime.

If they're not configurable, I wouldn't keep them together then.

Scaling is not an issue because the app is not going to get big. Why is
long names an issue? The number of variables will not exceed 50. Don't
names convert to some random short names in IL regardless of how long the
name was in the code?

No, it's a readability issue rather than anything else.

You said they are a good candidate to be in a class. Isn't that the same
what I was proposing? I want all these va riables in be in a custom class
so that I can refer to them using a single class name with the help of
intellisense instead of remembering which class contains them if they are
going to be scattered in different classes.

*If* they're logically linked as configuration parameters, that makes
sense. It doesn't if they're logically a constant which more reasonably
belongs to another class - which is suggested by the fact that you want
to initialise them from other classes.

 

[John Dalberg]

If they're not configurable, I wouldn't keep them together then.

They are changed during runtime which means they are configurable.

No, it's a readability issue rather than anything else.

Readability... long names has nothing to do with my issue. I don't
understand why you even bring this up. Anyways, it's all subjective. A 20
character name can be readible for one, too long for someone else.

*If* they're logically linked as configuration parameters, that makes
sense. It doesn't if they're logically a constant which more reasonably
belongs to another class - which is suggested by the fact that you want
to initialise them from other classes.

I don't see this discussion going to my desirable outcome. It's becoming
more like an argument than "this is how you do it" solution. Thanks for
your input.

John Dalberg

 

[Jon Skeet [C# MVP]]

I don't see this discussion going to my desirable outcome. It's becoming
more like an argument than "this is how you do it" solution. Thanks for
your input.

Agreed. I still don't think you should be doing what you want to do,
but...

public class Constants // Bad name if they change during runtime
{
public static readonly Name1 = A.ComputeName1();
public static readonly Name2 = B.ComputeName2();
// etc
}

(You could also make them properties rather than public fields.)

 

[Ken]

I used a module to do this, I know someone declared it seemed to be the
"Old" way - Although I did not wish to make them read only and only I wanted
to persist my variables.


I think that this is one way you could do it..

I hope this helps.