How to make constants available for the whole application?

[Bill Nguyen]

I need to make a set of constants to be available for the whole application.
Public const is confined to the form from which constants are declared.
Is there a way to declare once and all forms can access the constant values?
Thanks
Bill

 

[Al Reid]

I need to make a set of constants to be available for the whole application.
Public const is confined to the form from which constants are declared.
Is there a way to declare once and all forms can access the constant values?
Thanks
Bill

Place them in a standard module.

 

[Herfried K. Wagner [MVP]]

I need to make a set of constants to be available for the whole
application.
Public const is confined to the form from which constants are declared.
Is there a way to declare once and all forms can access the constant
values?

If you place them in a class, you will have to qualify the constant's names
with the name of the class containing the constant definitions (e.g.
'Form1.Constant1'). Alternatively you can place the constants in a module
in order to be able to access them without explicit qualification.

 

[alantolan]

By declaring a public constant in a class you can make it visible
anywhere that class is visible, it just needs to be accessed using the
class name

e.g.

public class Widget
public const MAX_SIZE as integer = 17
end class


... < some other code >

if (size < Widget.MAX_SIZE) then
DoSomething
end if


Also, declaring them in a module will make them visible anywhere that
module is visible.

e.g.

public module StdDefs
public const MAX_SIZE as integer = 17
end module

if (size < MAX_SIZE) then
DoSomething
end if



I really dislike the module approach. Some of that is just my Java
background whispering, "Modules, we doan need no stinkin' modules. Just
use classes", but I also dislike the idea of stuffing all the various
constants that one needs for an application into a single std defs
module.

How many constants REALLY need to be accessed everywhere and even those
which do, why are they not associated with classes.

So far I have it possible to always associate constants with
appropriate classes.
Prepending the class name may mean extra typing but so does using
variable names of more that 2 chars in length; the amount of typing
(within reason) should not be the only selection criterion and the
class name usually helps explain the context/use of the constant.

 

[Herfried K. Wagner [MVP]]

public module StdDefs
public const MAX_SIZE as integer = 17
end module

if (size < MAX_SIZE) then
DoSomething
end if


I really dislike the module approach. Some of that is just my Java
background whispering, "Modules, we doan need no stinkin' modules. Just
use classes", but I also dislike the idea of stuffing all the various
constants that one needs for an application into a single std defs
module.

Well, I dislike the use of interfaces for grouping constants which is often
used in Java because of the /lack of/ semantically more correct modules.

How many constants REALLY need to be accessed everywhere and even those
which do, why are they not associated with classes.

Imagine a bunch of p/invoke declares, type definitions, and constants. IMO
modules are a good solution for grouping these declares, ...

BTW: You can even fully qualify a constant defined in a module.

 

[Bill Nguyen]

Thank you all.
It worked fine for me either way.

Bill

 

[alantolan]

Imagine a bunch of p/invoke declares, type definitions, and constants. IMO

modules are a good solution for grouping these declares, ...

The point was that such things as p/invoke declares constants, et al.
are generally not used randomly throughout the system, they provide
support for some specified functionality that functionality can be
grouped together within a class.

The usual problem with a general 'definitions and constants' module is
that it becomes a dumping ground for all items that "we don't know
where it should really go", or "we don't have time to sort out at the
moment".

If we don't have just one module and spend time splitting them up in
some useful fashion then why would one not put them into a class.

 

[Herfried K. Wagner [MVP]]

The point was that such things as p/invoke declares constants, et al.
are generally not used randomly throughout the system, they provide
support for some specified functionality that functionality can be
grouped together within a class.

The usual problem with a general 'definitions and constants' module is
that it becomes a dumping ground for all items that "we don't know
where it should really go", or "we don't have time to sort out at the
moment".

I don't see any difference in creating a class or module to contain all the
stuff "dumping around". This problem is /not/ related to the existance and
use of modules.

 

[alantolan]

The OP was a question on how to make constants available to the whole
program; modules or classes can be used for either. I stated a
personal preference for the classes option to which you replied that
modules were 'sematically more correct'

I am still confused by that comment.

VB.Net is an OO language, it behooves one to use OO designs and not
just cut-and-paste VB6 code, tweaking it until it compiles.

Constants in Modules:
If an application is designed/implemented as a set of inter-relating
classes/objects then there should be no need for 'naked' constants in a
module.

P/Invoke Declares In Modules:
Why should the application code see/know about p/invoke declarations?
The functionality should be wrapped in a class and that class used,
reducing the 'surface area' that the application developer needs to
know/remember.

Classes as Dumping Grounds:
Although one can construct a class to act like a module and then use it
as a dumping ground for misc defs, why would one?

My point was that associating the constants with the appropriate class
is a better option than putting them into a general module, not that
one is incapable of using a class like a dumping ground. Better tools
do not prevent poor design, they just provide and opportunity to do
things better than 'the way we've always done it'

Alan.

 

[Ross Presser]

My point was that associating the constants with the appropriate class
is a better option than putting them into a general module, not that
one is incapable of using a class like a dumping ground. Better tools
do not prevent poor design, they just provide and opportunity to do
things better than 'the way we've always done it'

I don't understand why you consider it a "better design" to create a class
that does nothing but group a bunch of constants together, even if they are
semantically related, if there is no more substance to the class.

One step further, I fail to see the joy in a class that has no member or
private variables, only shared methods and constants. If I'm calling the
exact same function every time, and it has no internal state of any kind,
and I always have to feed it a full set of arguments, why should it pretend
it's part of a class or an object?

 

[Herfried K. Wagner [MVP]]

Ross,

I don't understand why you consider it a "better design" to create a class
that does nothing but group a bunch of constants together, even if they
are
semantically related, if there is no more substance to the class.

One step further, I fail to see the joy in a class that has no member or
private variables, only shared methods and constants. If I'm calling the
exact same function every time, and it has no internal state of any kind,
and I always have to feed it a full set of arguments, why should it
pretend
it's part of a class or an object?

That's what my concern is about. Classes are IMO a language feature used to
model entities, and thus not intended for /grouping/ objects (functions,
constants, ...) with a loose relationship.

However, I don't think that modules are the best possible solution because
they are automatically imported. I would prefer modules which need to be
imported explicitly or whose members do not always appear in IntelliSense.

 

[alantolan]

I was neccessarily talking about a class that contains only constants
(though that is not intrinically a problem), I was talking about
associating constants with an appropriate class rather than sticking
them in a general holding tank.

Simple example, Client Colors

Say we have an application and want to have all the forms use a given
color scheme (we want a specific one rather than use the Windows
scheme)

Instead of setting them on all the forms at design time (which will be
tedious to change when someone in marketing says, 'Oh! Puce is the new
black!"), we have a set of constants for the colors.


Where do we put them?

We can stick them in a module, or
We can place them in, say, a ClientConfig class along with the default
screen height and width and whatever other values that we reckon are
appropriate for Client Configuration.

Does it have any functionality included? Perhaps not, at first; we have
a fixed set of colors that the user is not allowed to change.

But if at some point we decide to allow the users to customize the
client colors we can add that functionality to this class and with very
little (if any) change to the application code we now have a client
with customizable colors.

I do not see that a module is 'sematically more correct' or even
semantically anything. A module started off life as ' the source code
for a program', evolved into 'a compilation unit' and now to me seems
like a vermiform source file. I personally think they are not useful
but that's a free opinion (and worth every penny)

My comments boil down to

1) A single large source file (be it class or module) for holding all
the constants that may need global scope, is a bad thing.

2) On anecdotal evidence, one a StdDef.bas gets created, everything
gets dumped in there. Almost by reflex. We're short on time, don't
have a chance to work through where a new 'something' should be put.
Stick it here and we'll get back to it later... promise.

3) Constants are given a global scope when they need to used in more
than one place but they can be usually said to 'belong' to a specific
piece of functionality and should be associated with that.

e.g.
ClientConfig.SCREEN_WIDTH
MyApplication.APP_NAME

4) Sort of OT; Low level constants and declares should not be visble
to the application code at all.
P/invoke delcarations, OS constants (say, WS_EX_TOOLWINDOW or
SIZE_MINIMIZED) should be wrapped by a class and that functionality
invoked through the class.
This removes the need for them to be in the global namespace at all.

Alan.