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" <no****@nospam. ssswrote in message
news:20******** ***********@new sreader.com...

>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

[John Dalberg]

"VJ" <no***********@ yahoo.comwrote:

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.Nam e1 = "Some name";
}
}
class B
{
B()
{
MyConstants.Nam e2 = "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
---------------------------------------------------------

>
VJ

"John Dalberg" <no****@nospam. ssswrote in message
news:20******** ***********@new sreader.com...

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

[Jon Skeet [C# MVP]]

John Dalberg <no****@nospam. ssswrote:

<snip>

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.MaxIn t32 and
Constants.MaxDo uble etc.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[VJ]

Singleton Pattern will help here?

VJ

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

John Dalberg <no****@nospam. ssswrote:

<snip>

>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.MaxIn t32 and
Constants.MaxDo uble etc.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[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?

"John Dalberg" <no****@nospam. ssswrote in message
news:20******** ***********@new sreader.com...

>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

[Jon Skeet [C# MVP]]

VJ <no***********@ yahoo.comwrote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[John Dalberg]

Jon Skeet [C# MVP] <sk***@pobox.co mwrote:

VJ <no***********@ yahoo.comwrote:

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.

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]]

John Dalberg <no****@nospam. ssswrote:

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.

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

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?

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[John Dalberg]

Jon Skeet [C# MVP] <sk***@pobox.co mwrote:

John Dalberg <no****@nospam. ssswrote:

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.

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

They are changed during runtime which means they are configurable.

>

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?

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.

>

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.

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