Static Members

[Mark]

Hello Friends
Please check the code below.
One in C# and other in VB .Net
In C# I am not able to access a static property by an
instance variable, but in VB I can do it easily.

The Error is

Static member 'ClassInCS.ABC. MyInt' cannot be accessed
with an instance reference; qualify it with a type name
instead

Can anybody explain why there is such a difference between
to language?
Is this advantage to VB??
Or it doesn't fit in rule of OOP?
Regards
Mark.

C# Code

class MyClass{
[STAThread]
static void Main(string[] args){
Console.WriteLi ne(ABC.MyInt);
ABC a;
Console.WriteLi ne(a.MyInt); //ERROR
a = new ABC();
Console.WriteLi ne(a.MyInt); //ERROR
}
}
class ABC{
private static int m_MyInt = 1;
public static int MyInt{
get{
return m_MyInt;
}
set{
m_MyInt = value;
}
}
}

VB Code

Sub Main()
Console.WriteLi ne(XYZ.MyInt)
Dim x As XYZ
Console.WriteLi ne(x.MyInt)
x = New XYZ()
Console.WriteLi ne(x.MyInt)
End Sub
Class XYZ
Public Const MyPConst As Integer = 2
Private Shared m_MyInt As Int32 = 1
Public Shared Property MyInt() As Int32
Get
Return m_MyInt
End Get
Set(ByVal Value As Int32)
m_MyInt = Value
End Set
End Property
End Class

[Daniel Billingsley]

Then I'll just say that your actual point has been somewhat of a moving
target to say the least, so you shouldn't be surprised that none of us "got
it".

"Cor" <no*@non.com> wrote in message
news:uc******** ******@TK2MSFTN GP10.phx.gbl...

Daniel,

In most messages about this is the newsgroup Csharp deleted; I think that is good, what has that newsgroup to do with this discussion.

If you follow the thread well, I explained to OHM that I agreed with the
basic of the arguments of Jon, OHM and Armin about the use of the code.
However, my point was only that I understood from OHM that it should be
preserve in the language. If that would be the point, every language older
than 1 year should be newly written again.

You should deny it but things as the == are only in the language because in past there was no alternative to do it, while I think there are plenty of
other possibilities for that now. I said already that it is not a point that I think it should be changed, just as sample. Program languages are growing like natural languages; you cannot change that just because you think a word is not good.

You find my text about natural language babble, sorry for you but program
languages acts very much like that. Not everything is good in it; many
things have a historical background like natural languages and cannot
correct afterwards.

Before you ask why I did not tell before that the fact itself I did agree,
that was because Jon did not give me a chance for that because he wanted to hear that I was wrong, while I was not talking about what he was asking.

Cor

[Tom Leylan]

"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> wrote...

I hope you didn't get the idea I was disagreeing with Jon. I meant only to play devil's advocate for a minute and offer one possible way of looking at it differently.
Oh not at all, I saw your point.
And by that way of looking at your statement isn't correct.
A building is a manifestation of the blueprint, and as such it's length
property could really be "inherited" from the static length property on the blueprint.
I guess. I'd suggest that if the building is a manifestation of the
blueprint then the building's length is a manifestation of the length
property contained in the blueprint. I don't see inheritance at work, the
blueprint is a sheet of paper.
But I just thought of something that would seem very weird to me. what if
you implement a class factory model whereby a static method of the class
returns an instance. That would seem VERY ugly if the instance could also
be a factory, which it could in VB, right? Ugh!
Absolutely right. You don't have to actually instantiate it either. You
can declare an instance of a class factory and use the instance variable as
a class factory. If you do instantiate it you can use that instance to
create others too of course.
So, again I say even if we could understand one way of looking at things
which might explain keeping that functionality, I agree there are too many
cases where things get muddy right quick.

And that tends to be the point. It is one of the reasons that languages
with lots of legacy constructs tend to become hard to maintain. Keeping the
old syntax around sounds good on the surface (we all know the reasons) but
it ends up costing more money and forcing people to update (or simply use
the old compiler.) Retaining backward compatibility has been tried and it
costs businesses a fortune.

I mostly have been fixing old apps in the last few years and I run across
apps with 3 or 4 generations of syntax in it. Even from one line to the
next in the same module. It's a nightmare and testing becomes even more
important because the kinds of bugs that surface are extremely subtle.

Tom

[Cor]

Hi Daniel,

Follow the thread where I started I did not move the target which I started
one single pixel.
Jon is first answering that point and moves then back to the static member,
maybe because he lost his powder to hit the target I was started with.

If you don't mind I want this make EOT.

Cor

[Sami Vaaraniemi]

First off, I want to point out that in general on this topic I fully agree
with Jon. I hope that i'm not fueling the fire here any more, but during my
many years of writing software I've learned that ambiguity is simply evil
and will sooner or later be the underlying cause for that angry phone call
from a customer.

Rest is inline.

"Tom Leylan" <ge*@iamtiredof spam.com> wrote in message
news:un******** ******@TK2MSFTN GP11.phx.gbl...

"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> wrote...

I hope you didn't get the idea I was disagreeing with Jon. I meant only

to

play devil's advocate for a minute and offer one possible way of looking

at

it differently.

Oh not at all, I saw your point.

And by that way of looking at your statement isn't correct.
A building is a manifestation of the blueprint, and as such it's length
property could really be "inherited" from the static length property on

the

blueprint.

I guess. I'd suggest that if the building is a manifestation of the
blueprint then the building's length is a manifestation of the length
property contained in the blueprint. I don't see inheritance at work, the
blueprint is a sheet of paper.

Daniel's idea of an instance "inheriting " from its class is not that far
fetched IMO. Conceptually, an instance of class X is-an-X. Conceptually, an
instance is everything its class is except for one difference, the
substance. That's exactly what inheritance is: subclass of class X is
everything X is plus it may add new behavior and/or properties. Similarly an
instance x of class X is like X with just one additional property, namely
the memory location where the instance resides. You could think of
instantiation as just another case of inheritance.

I really don't have the time for all this,
Sami