By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,627 Members | 2,339 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,627 IT Pros & Developers. It's quick & easy.

Static Class Constants (VB 2005)

P: n/a
Is there any way to create a constant in a class that can be used both with
an instantiated object and without. For example:

dim ClassConst as string = myClass.ConstantString

dim myObj = new MyClass
ClassConst = myObj.ConstantString

Inside the class MyClass

Class MyClass

public const ConstantString = "Some Constant String"

End Class

In Beta 2, ConstantString was available in either of the above cases without
complaint. In the RTM version, I can't do both. I don't want to turn off
the warning as doing so may actually introduce another bug in my code later
because I didn't see the warning.

Thanks,
Mike.

Dec 8 '05 #1
Share this Question
Share on Google+
29 Replies


P: n/a
If it's a constant, why not always reference it through the type name? What
do you gain by accessing it through an instance?

"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:uj*************@TK2MSFTNGP14.phx.gbl...
Is there any way to create a constant in a class that can be used both
with
an instantiated object and without. For example:

dim ClassConst as string = myClass.ConstantString

dim myObj = new MyClass
ClassConst = myObj.ConstantString

Inside the class MyClass

Class MyClass

public const ConstantString = "Some Constant String"

End Class

In Beta 2, ConstantString was available in either of the above cases
without
complaint. In the RTM version, I can't do both. I don't want to turn off
the warning as doing so may actually introduce another bug in my code
later
because I didn't see the warning.

Thanks,
Mike.

Dec 8 '05 #2

P: n/a
Marina,

"Marina" <so*****@nospam.com> schrieb:
If it's a constant, why not always reference it through the type name?
What do you gain by accessing it through an instance?


What do you loose by accessing it through an instance?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 8 '05 #3

P: n/a
Michael
i use the release version of Visual studio 2005 ( professional edition )

Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

Dim ClassConst As String = XMyClass.ConstantString

MsgBox(ClassConst)

Dim myObj = New XMyClass

ClassConst = myObj.ConstantString

MsgBox(ClassConst)

End Sub

End Class

Class XMyClass

Public Const ConstantString = "Some Constant String"

End Class

this works without anny problems on my dev computer ( no warnings )

regards

Michel Posseth [MCP]
"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:uj*************@TK2MSFTNGP14.phx.gbl...
Is there any way to create a constant in a class that can be used both
with
an instantiated object and without. For example:

dim ClassConst as string = myClass.ConstantString

dim myObj = new MyClass
ClassConst = myObj.ConstantString

Inside the class MyClass

Class MyClass

public const ConstantString = "Some Constant String"

End Class

In Beta 2, ConstantString was available in either of the above cases
without
complaint. In the RTM version, I can't do both. I don't want to turn off
the warning as doing so may actually introduce another bug in my code
later
because I didn't see the warning.

Thanks,
Mike.

Dec 8 '05 #4

P: n/a
Code readability.

Mike.

"Marina" <so*****@nospam.com> wrote in message
news:OE*************@tk2msftngp13.phx.gbl...
If it's a constant, why not always reference it through the type name? What do you gain by accessing it through an instance?

"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:uj*************@TK2MSFTNGP14.phx.gbl...
Is there any way to create a constant in a class that can be used both
with
an instantiated object and without. For example:

dim ClassConst as string = myClass.ConstantString

dim myObj = new MyClass
ClassConst = myObj.ConstantString

Inside the class MyClass

Class MyClass

public const ConstantString = "Some Constant String"

End Class

In Beta 2, ConstantString was available in either of the above cases
without
complaint. In the RTM version, I can't do both. I don't want to turn off the warning as doing so may actually introduce another bug in my code
later
because I didn't see the warning.

Thanks,
Mike.



Dec 8 '05 #5

P: n/a
There are times when accessing through an instance makes more sense - it
ensures I'm working with the correct object/class type. Other times,
accessing through the class type make more sense - when trying to verify
class type of an unknown string representation of the object. In the latter
case, class type verification can then be done without the overhead of
creating an object that then gets immediately thrown away.

Mike Ober.

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OA**************@TK2MSFTNGP15.phx.gbl...
Marina,

"Marina" <so*****@nospam.com> schrieb:
If it's a constant, why not always reference it through the type name?
What do you gain by accessing it through an instance?


What do you loose by accessing it through an instance?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>


Dec 8 '05 #6

P: n/a
Apparently you lose the ability to compile without getting a warner. You
also lose code clarity, as now it is not obvious this is a constant. It
could just be an instance property of the class, and it's not at all obvious
that it is not. Where as seeing the type name in front, you see that this
something that exists only once for the class.

The point is, if you don't gain anything by doing it, and you lose
readability, then why do it?

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OA**************@TK2MSFTNGP15.phx.gbl...
Marina,

"Marina" <so*****@nospam.com> schrieb:
If it's a constant, why not always reference it through the type name?
What do you gain by accessing it through an instance?


What do you loose by accessing it through an instance?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 8 '05 #7

P: n/a
Regardless of Option Explicit and Option Strict settings on a brand new form
with a single button, I get the error "Access of shared member, constant
member, enum member or nested type through an instance; qualifying
expression will not be evaluated." on your code sample. VS 2005 Standard
RTM.

Mike.

"m.posseth" <mi*****@nohausystems.nl> wrote in message
news:ev**************@TK2MSFTNGP14.phx.gbl...
Michael
i use the release version of Visual studio 2005 ( professional edition )

Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

Dim ClassConst As String = XMyClass.ConstantString

MsgBox(ClassConst)

Dim myObj = New XMyClass

''''''''''''' Error is on this line ClassConst = myObj.ConstantString

MsgBox(ClassConst)

End Sub

End Class

Class XMyClass

Public Const ConstantString = "Some Constant String"

End Class

this works without anny problems on my dev computer ( no warnings )

regards

Michel Posseth [MCP]
"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:uj*************@TK2MSFTNGP14.phx.gbl...
Is there any way to create a constant in a class that can be used both
with
an instantiated object and without. For example:

dim ClassConst as string = myClass.ConstantString

dim myObj = new MyClass
ClassConst = myObj.ConstantString

Inside the class MyClass

Class MyClass

public const ConstantString = "Some Constant String"

End Class

In Beta 2, ConstantString was available in either of the above cases
without
complaint. In the RTM version, I can't do both. I don't want to turn off the warning as doing so may actually introduce another bug in my code
later
because I didn't see the warning.

Thanks,
Mike.



Dec 8 '05 #8

P: n/a
If this is about a constant, how does that help ensure you are working with
the right class? There is no inheritance issue here.

"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:OI**************@TK2MSFTNGP10.phx.gbl...
There are times when accessing through an instance makes more sense - it
ensures I'm working with the correct object/class type. Other times,
accessing through the class type make more sense - when trying to verify
class type of an unknown string representation of the object. In the
latter
case, class type verification can then be done without the overhead of
creating an object that then gets immediately thrown away.

Mike Ober.

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OA**************@TK2MSFTNGP15.phx.gbl...
Marina,

"Marina" <so*****@nospam.com> schrieb:
> If it's a constant, why not always reference it through the type name?
> What do you gain by accessing it through an instance?


What do you loose by accessing it through an instance?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>


Dec 8 '05 #9

P: n/a
"Marina" <so*****@nospam.com> schrieb:
If this is about a constant, how does that help ensure you are working
with the right class? There is no inheritance issue here.


That's true, but especially when dealing with public constants it seems
completely irrelevant to me whether or not the member belongs to an instance
or the class itself. I agree that it doesn't make much sense to obtain a
reference to an object using complicated code only to access one of the
public constants of the class.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 8 '05 #10

P: n/a
I think for readability issues, and to make the developer aware that they
are accessing a constant or static member, that warning is there.

And that is why it is a warning, not an error. So if it's something one
wants to do, they can. Though again, for readability and consistentcy
reasons my opinion is that the class name should be used in these cases.

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ez*************@TK2MSFTNGP12.phx.gbl...
"Marina" <so*****@nospam.com> schrieb:
If this is about a constant, how does that help ensure you are working
with the right class? There is no inheritance issue here.


That's true, but especially when dealing with public constants it seems
completely irrelevant to me whether or not the member belongs to an
instance or the class itself. I agree that it doesn't make much sense to
obtain a reference to an object using complicated code only to access one
of the public constants of the class.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 8 '05 #11

P: n/a
Yes, this is a change in the VB.NET language and you will be force to change
it. C#, and other languages have always done it this way.

I think for the sake of better code clarity it was a good move, also this
does not require any more work from the developer.
It's is now obvious if a line of code is calling a shared/static or instance
specific method.
It can be a pain when moving code from 1.0 to 2.0, but at least the error is
easy to identify, and easy to fix.

Schneider.


"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:uq*************@TK2MSFTNGP15.phx.gbl...
Regardless of Option Explicit and Option Strict settings on a brand new form with a single button, I get the error "Access of shared member, constant
member, enum member or nested type through an instance; qualifying
expression will not be evaluated." on your code sample. VS 2005 Standard
RTM.

Mike.

"m.posseth" <mi*****@nohausystems.nl> wrote in message
news:ev**************@TK2MSFTNGP14.phx.gbl...
Michael
i use the release version of Visual studio 2005 ( professional edition )

Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

Dim ClassConst As String = XMyClass.ConstantString

MsgBox(ClassConst)

Dim myObj = New XMyClass


''''''''''''' Error is on this line
ClassConst = myObj.ConstantString

MsgBox(ClassConst)

End Sub

End Class

Class XMyClass

Public Const ConstantString = "Some Constant String"

End Class

this works without anny problems on my dev computer ( no warnings )

regards

Michel Posseth [MCP]
"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:uj*************@TK2MSFTNGP14.phx.gbl...
Is there any way to create a constant in a class that can be used both
with
an instantiated object and without. For example:

dim ClassConst as string = myClass.ConstantString

dim myObj = new MyClass
ClassConst = myObj.ConstantString

Inside the class MyClass

Class MyClass

public const ConstantString = "Some Constant String"

End Class

In Beta 2, ConstantString was available in either of the above cases
without
complaint. In the RTM version, I can't do both. I don't want to turn off the warning as doing so may actually introduce another bug in my code
later
because I didn't see the warning.

Thanks,
Mike.



Dec 8 '05 #12

P: n/a
"schneider" <ab*@fgfdgfd.com> schrieb:
Yes, this is a change in the VB.NET language and you will be force to
change
it.
No! It's a warning which can be disabled.
C#, and other languages have always done it this way.


VB is not C#. The keyword is called 'Shared' in VB.NET. Shared members are
/shared/ between /all/ instances of a class. They belong to all instances
and thus are accessible on instance variables.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 8 '05 #13

P: n/a
Mike,

\\\
Public Class myConstantClass
Private Shared mValue As String = "WhatEverConstantString"
Public Shared ReadOnly Property ConstantString() As String
Get
Return mValue
End Get
End Property
End Class
///

I hope this helps,

Cor
Dec 8 '05 #14

P: n/a
"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:
\\\
Public Class myConstantClass
Private Shared mValue As String = "WhatEverConstantString"
Public Shared ReadOnly Property ConstantString() As String
Get
Return mValue
End Get
End Property
End Class
///


I doubt that this will solve the OP's problem, which is the same in both
cases, regardless if you are using a constant or a read-only property: A
shared member is accessed through a variable of the class' type.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 8 '05 #15

P: n/a
i have the idea that this is not what the TS wants
and Cor why not
Public Class myConstantClass

Public Shared ReadOnly Property ConstantString() As String

Get

Return "WhatEverConstantString"

End Get

End Property

End Class

And indeed it turned out that my IDE had two warning options off

so with this code

Public Class Form1

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

Dim ClassConst As String = XMyClass.ConstantString

MsgBox(ClassConst)

Dim myObj As New XMyClass

ClassConst = myObj.ConstantString

MsgBox(ClassConst)

End Sub

End Class

Class XMyClass

Public Const ConstantString As String = "Some Constant String"

End Class

i see a nag under this line myObj.ConstantString

i think the best solution would be to declare all these sort constants as
readonly property`s with the shared keyword

regards

Michel posseth


"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:
\\\
Public Class myConstantClass
Private Shared mValue As String = "WhatEverConstantString"
Public Shared ReadOnly Property ConstantString() As String
Get
Return mValue
End Get
End Property
End Class
///


I doubt that this will solve the OP's problem, which is the same in both
cases, regardless if you are using a constant or a read-only property: A
shared member is accessed through a variable of the class' type.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 8 '05 #16

P: n/a

Herfried K. Wagner [MVP] wrote:

Sorry Herfried, I have to take issue with you on this one I'm afraid
"schneider" <ab*@fgfdgfd.com> schrieb:
Yes, this is a change in the VB.NET language and you will be force to
change
it.
No! It's a warning which can be disabled.


It's a warning that you're doing something wrong.
C#, and other languages have always done it this way.
VB is not C#.
The keyword is called 'Shared' in VB.NET.


There's a keyword called 'AddressOf' as well, but it doesn't get the
address of anything.
Shared members are
/shared/ between /all/ instances of a class.
They belong to all instances
No, conceptually they belong to the *class*, not to any instance.
and thus are accessible on instance variables.


Them being accessible on instance variables was to my mind a language
design error.

Note that Shared items can be accessed even when a class *cannot* have
instances - how can they then be said to 'belong to all instances' ?

This new compiler warning is a good thing.

--
Larry Lard
Replies to group please

Dec 8 '05 #17

P: n/a
"Larry Lard" <la*******@hotmail.com> schrieb:
Sorry Herfried, I have to take issue with you on this one I'm afraid
No problem. I like those "issues" ;-).
> Yes, this is a change in the VB.NET language and you will be force to
> change
> it.


No! It's a warning which can be disabled.


It's a warning that you're doing something wrong.


Well, it's an error if you configure the compiler to raise a complile-time
error. And it's not problem if you configure the compiler to take no action
at all. Although I have never accessed a shared member through an instance
variable, I don't think that this is such a big problem. Maybe it's a
problem for C# developers who come to VB.
> C#, and other languages have always done it this way.


VB is not C#.
The keyword is called 'Shared' in VB.NET.


There's a keyword called 'AddressOf' as well, but it doesn't get the
address of anything.


Well, that's another story. I remember Bruce McKinney first complaining
about the existance of 'AddressOf' in VB.NET some years ago. I believe that
a keyword is important, regardless of its name. Personally, I do not like
the C# solution.
Shared members are
/shared/ between /all/ instances of a class.
They belong to all instances


No, conceptually they belong to the *class*, not to any instance.


As already said, this doesn't apply to VB.NET. It's an implementation
detail that they do not belong to a certain instance.

"Visual Basic Language Specification -- 9.2.4 'Shared' Methods":

| The 'Shared' modifier indicates a method is a /shared method/.
| A shared method does not operate on a specific instance of a type
| and may be invoked directly from a type rather than through a particular
| instance of a type. It is valid, however, to use an instance to qualify
| a shared method.

"Visual Basic Language Concepts -- Shared Members":

| Shared members are properties, procedures, and fields that are shared
| by all instances of a class.

"Visual Basic Language Reference -- 'Shared'":

| The 'Shared' keyword indicates that one or more declared programming
| elements are shared. Shared elements are not associated with a specific
| instance of a class or structure. You can access them by qualifying them
| either with the class or structure name, or with the variable name of a
| specific instance of the class or structure.

....
and thus are accessible on instance variables.


Them being accessible on instance variables was to my mind a language
design error.

Note that Shared items can be accessed even when a class *cannot* have
instances - how can they then be said to 'belong to all instances' ?


They belong to the set of instances, which can be empty.
This new compiler warning is a good thing.


Well, I'm glad that it can be disabled...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 8 '05 #18

P: n/a
Michael and Herfried,

Just because my idea was, what is the benefit of a constant in 2005.

In my opinion is this much nicer to get the same result.

I was sure somebody would give a reaction on my sample.

Cor
Dec 9 '05 #19

P: n/a
"Herfried K. Wagner [MVP]"

Probably we don't disagree if you have read what I write 3 or 4 times.
VB is not C#. The keyword is called 'Shared' in VB.NET. Shared members
are /shared/ between /all/ instances of a class. They belong to all
instances and thus are accessible on instance variables.

And the normal way is to place those in the first (0) stack of the program.
I don't know how Net does it, however I assume the same or otherwise the
method will result in the same.

In my opinion it is what is called a shared class no class but a module.

That in the C world people started to call this a class because of the fact
that it was in almost the same way described does not mean that it is a
class. (Despite that in my opinion all dificult ways in describing are
choosen to avoid to tell this)

I see not why it can than not used as a real class and automaticly take no
care of the "Shared" keyword..

That in the German language "See" is in English "Lake" what in Dutch "Meer"
while in French "Mer" is the same as in English "See" does not say anything
about the used object at all.

Just my thought,

Cor
Dec 9 '05 #20

P: n/a
Hi Cor ,
Maybe my reponse should have been more clear
i think the best solution would be to declare all these sort constants as
readonly property`s with the shared keyword

cause wasn`t this wat you showed , however it looks like this is a
workaround for the TS ( it is not exactly what he wants )

i was only wondering why you did not do this ( maybe i am missing a obvious
reasson )

Public Class myConstantClass

Public Shared ReadOnly Property ConstantString() As String

Get

Return "WhatEverConstantString"

End Get

End Property

End Class
regards

Michel Posseth


"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:uL**************@TK2MSFTNGP14.phx.gbl... Michael and Herfried,

Just because my idea was, what is the benefit of a constant in 2005.

In my opinion is this much nicer to get the same result.

I was sure somebody would give a reaction on my sample.

Cor

Dec 9 '05 #21

P: n/a
Ah,

Sorry Michel, I see it now.

I was hoping on a long discussion about saving one bit by doing it not this
way.
Of course just use the string is even better.

:-)))

Cor
Dec 9 '05 #22

P: n/a
doh,

again a possibility for misunderstanding

I was hoping on a long discussion about saving one bit by doing it not
this way.


I was hoping on a long discussion about saving one bit by doing it by not
using a read only property but a constant

:-)

Cor
Dec 9 '05 #23

P: n/a
Cor,

"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:
VB is not C#. The keyword is called 'Shared' in VB.NET. Shared members
are /shared/ between /all/ instances of a class. They belong to all
instances and thus are accessible on instance variables. [...]
In my opinion it is what is called a shared class no class but a module.


I agree. I have never liked the idea of "static classes" as available in
C#. Static classes are semantically nonsense. They are no classes, and
they should not be types. They are simply a grouping mechanism which should
be as lightweight as namespaces are. To me it seems that some OOP purists
simply didn't want to use a semantically more correct term such as module,
unit, or group because it's not an OO term.
That in the C world people started to call this a class because of the
fact that it was in almost the same way described does not mean that it is
a class. (Despite that in my opinion all dificult ways in describing are
choosen to avoid to tell this)


Exactly true!

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 9 '05 #24

P: n/a
"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:
Just because my idea was, what is the benefit of a constant in 2005.

In my opinion is this much nicer to get the same result.

I was sure somebody would give a reaction on my sample.


Read-only properties and constants are treated differently by the compiler.
While constants' values are embedded into assemblies using your library at
compile-time, the value of read-only properties is determined at runtime.
Thus it's not necessary to recompile dependent libraries when changing the
return value of a read-only property opposed to a constants.

I use public constants in very few cases only. Often constants are an
implementation detail only.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 9 '05 #25

P: n/a
Herfried,
Read-only properties and constants are treated differently by the
compiler. While constants' values are embedded into assemblies using your
library at compile-time, the value of read-only properties is determined
at runtime. Thus it's not necessary to recompile dependent libraries when
changing the return value of a read-only property opposed to a constants.

I use public constants in very few cases only. Often constants are an
implementation detail only.

Exact this answer was what I expected and than I find a read-only property
something nicer.

However are you sure of that assembly part, I did not try it yet, however I
am almost sure that in the way Michel made it, (forgive me my mistake) will
result in the same constant in the ILS. Those strings are immutable you
know?

:-)

Cor
Dec 9 '05 #26

P: n/a
Beta 2 worked - a public constant could be accessed via the Class Name or
via an Object reference.

Mike.

"schneider" <ab*@fgfdgfd.com> wrote in message
news:uM***************@TK2MSFTNGP15.phx.gbl...
Yes, this is a change in the VB.NET language and you will be force to change it. C#, and other languages have always done it this way.

I think for the sake of better code clarity it was a good move, also this
does not require any more work from the developer.
It's is now obvious if a line of code is calling a shared/static or instance specific method.
It can be a pain when moving code from 1.0 to 2.0, but at least the error is easy to identify, and easy to fix.

Schneider.


"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:uq*************@TK2MSFTNGP15.phx.gbl...
Regardless of Option Explicit and Option Strict settings on a brand new

form
with a single button, I get the error "Access of shared member, constant
member, enum member or nested type through an instance; qualifying
expression will not be evaluated." on your code sample. VS 2005 Standard RTM.

Mike.

"m.posseth" <mi*****@nohausystems.nl> wrote in message
news:ev**************@TK2MSFTNGP14.phx.gbl...
Michael
i use the release version of Visual studio 2005 ( professional edition )
Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

Dim ClassConst As String = XMyClass.ConstantString

MsgBox(ClassConst)

Dim myObj = New XMyClass


''''''''''''' Error is on this line
ClassConst = myObj.ConstantString

MsgBox(ClassConst)

End Sub

End Class

Class XMyClass

Public Const ConstantString = "Some Constant String"

End Class

this works without anny problems on my dev computer ( no warnings )

regards

Michel Posseth [MCP]
"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:uj*************@TK2MSFTNGP14.phx.gbl...
> Is there any way to create a constant in a class that can be used both > with
> an instantiated object and without. For example:
>
> dim ClassConst as string = myClass.ConstantString
>
> dim myObj = new MyClass
> ClassConst = myObj.ConstantString
>
> Inside the class MyClass
>
> Class MyClass
>
> public const ConstantString = "Some Constant String"
>
> End Class
>
> In Beta 2, ConstantString was available in either of the above cases
> without
> complaint. In the RTM version, I can't do both. I don't want to turn
off
> the warning as doing so may actually introduce another bug in my

code > later
> because I didn't see the warning.
>
> Thanks,
> Mike.
>
>
>




Dec 9 '05 #27

P: n/a
I'm working with the interface to a legacy VMS system. Data records are
returned in a string of format "FileChannel & vbNL & RecordData". This
interface can return multiple records per call and each record can
potentially be from a different channel. I need to be able to do the
following:

dim basechannel as somechannel ' SomeChannel is an object that is created
based on the VMS RMS File definition, which I have access to and have a VB 6
cross compiler that generates the .NET VB2005 class object. (RMS allows
overlapping field layouts)

dim haveObjType2 as boolean = false
for each s as string in LegacyInterface.GetData(<VMSChannelStart>,
<lookupcriteria>, <NumberToGet>)
dim channel as string = LegacyInterface.GetChannel(s)
if ChannelType1.Channel = channel and haveObjType2 then
' Process ChannelType1 data only if ChannelType2 data has been found
dim objType1 as new ChannelType1(s)
' Do something with objType1

case ChannelType2.Channel:
dim objType2 as new ChannelType2(s)
haveObjType2 = true
' Do something with it
LegacyInterface.Update(objType2.Channel, objType2.buffer)

case ChannelType3.Channel
' not needed either
end select
next s

Why go through the overhead of creating non-required types. Also, in some
cases, I may have to create objType1 depending on what is returned in
objType2. I didn't design the underlying RMS database structure - it's not
even 1st Normal form. Note that I ALWAYS use Option Strict On and Option
Explicit On. I've had too many experiences where VB 6 didn't pick up a type
cast failure at compile time and the application didn't work as expected. I
want the compiler to tell me when there is a type casting problem.

Here's a sample of the output of the RMS cross compiler:

Option Explicit On
Option Strict On
Option Compare Text
Public Class COMMENT4
' Created with DefToCls v.4.1.10
' Created on #11/11/2005 1:58:33 PM#
' VMS Source File has VBTags
' VMS Source File Header for \\JAGUAR\VMSDEVHOME\def\4COMMENT.DEF
' !
' !TITLE: WA$SOURCE:4COMMENT.DEF
' !
' !22-DEC-95 NSB CREATED NEW DEF
' !31-MAY-96 MVD CHANGE COMMENT_TYPE TO 3 CHAR
' !01-AUG-96 MVD CHANGE COMMENT_TYPE TO 5 CHAR AND MOVE TO KEY
' !07-AUG-96 MVD CHANGE DATE TO 10 CHARACTERS
' !4-MAR-97 NSB ADDED SUB_TYPES VARIANT AND DOCUMENTAION
' !16-JAN-99 NSB MODIFIED TO THE FINAL FORMAT
' !
' ! THE NEW FORMAT
' !
' ! VB_CHANNEL=COMMENT
' ! VB_RECORD_LENGTH=105
' !
' RECORD TYPE$_4COMMENT

Public Const RecSize as Integer = 105

Private buffer As String
Public Sub New()
init
End Sub
Public Sub New(ByVal value As String)
buffer = LSet(value, 105)
End Sub
Public Sub init()
buffer = Space(105)
End Sub

' These two functions are to keep the code later simpler to read
Private Function fetch(ByVal start As Integer, ByVal chars As Integer) As
String
fetch = Mid(buffer, start, chars)
End Function
Private Sub putch(ByRef s As String, ByVal start As Integer, ByVal chars
As Integer)
Mid(buffer, start, chars) = LSet(s, chars)
End Sub

' VAX Channels
Public Const Channel as String = "COMMENT"

'DBServer Key Fields
Public Const VBKey_KEY0 as String = "KEY0"

'Key ACCT_NUM not in .OPN file
Public Const VBKey_ACCT_NUM as String = "ACCT_NUM"

'DBServer Data Fields
Public Property BUF() as String
Get
Return fetch(1, 105)
End Get
Set(ByVal value as string)
putch(value, 1, 105)
End Set
End Property
Public Property KEY0() as String
Get
Return fetch(1, 19)
End Get
Set(ByVal value as string)
putch(value, 1, 19)
End Set
End Property

' Multiple fields cut out - they follow the same code sequence as BUF and
KEY0

'Formatted Print Property
Public Shadows ReadOnly Property ToString(Optional ByVal prefix As String =
"", Optional ByVal indent As Boolean = False) As String
Get
Dim IndentChar As String
If indent Then IndentChar = vbTab Else IndentChar = ""
Dim fp As String = ""
fp &= IndentChar & "KEY0: '" & KEY0 & "'" & vbNewLine
fp &= IndentChar & "OFFICE: '" & OFFICE & "'" & vbNewLine
fp &= IndentChar & "ACCT_NUM: '" & ACCT_NUM & "'" & vbNewLine
fp &= IndentChar & "COMMENT_TYPE: '" & COMMENT_TYPE & "'" &
vbNewLine
fp &= IndentChar & "PRODUCT: '" & PRODUCT & "'" & vbNewLine
fp &= IndentChar & "T_IME: '" & T_IME & "'" & vbNewLine
fp &= IndentChar & "D_ATE: '" & D_ATE & "'" & vbNewLine
fp &= IndentChar & "COLLECTOR: '" & COLLECTOR & "'" & vbNewLine
fp &= IndentChar & "CMMT: '" & CMMT & "'" & vbNewLine
prefix = Trim$(prefix)
If prefix <> "" Then
Dim lines() As String = Split(fp, vbNewLine)
fp = ""
For i As Integer = LBound(lines) To UBound(lines)
If Left(lines(i), Len(IndentChar) + Len(prefix)) =
(IndentChar & prefix) Then fp &= lines(i) & vbNewLine
Next i
End If
Return fp
End Get
End Property

Public Function Clone() As COMMENT4
Return New COMMENT4(buffer)
End Function
End Class

Mike.

"Marina" <so*****@nospam.com> wrote in message
news:uP**************@TK2MSFTNGP14.phx.gbl...
If this is about a constant, how does that help ensure you are working with the right class? There is no inheritance issue here.

"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:OI**************@TK2MSFTNGP10.phx.gbl...
There are times when accessing through an instance makes more sense - it
ensures I'm working with the correct object/class type. Other times,
accessing through the class type make more sense - when trying to verify
class type of an unknown string representation of the object. In the
latter
case, class type verification can then be done without the overhead of
creating an object that then gets immediately thrown away.

Mike Ober.

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OA**************@TK2MSFTNGP15.phx.gbl...
Marina,

"Marina" <so*****@nospam.com> schrieb:
> If it's a constant, why not always reference it through the type name? > What do you gain by accessing it through an instance?

What do you loose by accessing it through an instance?

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B URL:http://classicvb.org/petition/


Dec 9 '05 #28

P: n/a
It depends on the optimizer. A read only property that returns a constant
string should be caught and converted to a constant at compile time. A read
only property that computes it's result based on internal object state
cannot be optimized into a single return value.

Mike Ober.

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
Herfried,
Read-only properties and constants are treated differently by the
compiler. While constants' values are embedded into assemblies using your library at compile-time, the value of read-only properties is determined
at runtime. Thus it's not necessary to recompile dependent libraries when changing the return value of a read-only property opposed to a constants.
I use public constants in very few cases only. Often constants are an
implementation detail only.
Exact this answer was what I expected and than I find a read-only property
something nicer.

However are you sure of that assembly part, I did not try it yet, however

I am almost sure that in the way Michel made it, (forgive me my mistake) will result in the same constant in the ILS. Those strings are immutable you
know?

:-)

Cor


Dec 9 '05 #29

P: n/a
"Michael D. Ober" <obermd.@.alum.mit.edu.nospam> schrieb:
It depends on the optimizer. A read only property that returns a constant
string should be caught and converted to a constant at compile time. A
read
only property that computes it's result based on internal object state
cannot be optimized into a single return value.


I have to disagree. Converting it to a constant at compile time for the
reasons described in another reply (stronger dependency between multiple
components).

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Dec 9 '05 #30

This discussion thread is closed

Replies have been disabled for this discussion.