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

[Steve]

I also agree with Jon. This is just one of many reasons why it is hard
to communicate with management that c# is better, and that you shouldn't
start new projects with vb.net just because you're "comfortabl e" with
it. And you know that if you try to explain this they simply won't
understand.

Sorry Cor, I agree with Jon on this.
Regards - OHM
Jon Skeet [C# MVP] wrote:

Cor <no*@non.com> wrote:

I respectfully disagree.

From the European languages has the English language something
strange.

While languages as German, French and Spanish are very strict and
other languages by instance Dutch have/are adopting in the language
not existing words from all kind of languages (Chinese, French,
Italian, Portuguese, Jadish etc) is English totally different.

It is (as far as I know) a mixture between the old French language,
original Gallic and the old North Sea language.

Therefore, English has many words, which are almost the same or
often the same that even does not look at each other.

In my opinion, that does not make the English language incorrect or
other languages better.

I don't see what relevance your analogy has. VB.NET allows you to
(perhaps unwittingly) write confusing code in a way that C# doesn't.
In C# you get told if you're trying to access something as if it were
an instance member - what's the downside of that? The only *possible*
benefit of the VB.NET way as far as I can see is that you can use

a.Method()
instead of
SomeVeryLongI ndeedAndAnnoyin gToReadTypeName .Method()

If you really want to avoid that, you can alias the type name -
although I'd be very wary about doing that.

So, as far as I can see there's a downside to the VB.NET way of doing
things, but no upside. In what way does that *not* make C# better in
this respect? (Presumably the reasoning for VB.NET working that way is
for compatibility reasons, but if so there should at least be an
option to turn it off, just like option strict.)

[Cor]

Hi Jon,

As often discussed C# and VB.net have both advantages but not in the code
itself.

The advantage VB.net that it is somehow like a natural language

The advantage of C# that it is more strict.

Both are good idea's but they conflict with each other.

That does not make in my opinion things absolute more better or worse.
It is just the point of view what you find important decide that.

And because I am writing this from the VB.language group I did make the
comparising with a natural language like English.
Cor

[Cor]

OHM,

See my comment at Jon.

Cor

[Jon Skeet [C# MVP]]

Cor <no*@non.com> wrote:

As often discussed C# and VB.net have both advantages but not in the code
itself.

The advantage VB.net that it is somehow like a natural language

The advantage of C# that it is more strict.

Both are good idea's but they conflict with each other.

That does not make in my opinion things absolute more better or worse.
It is just the point of view what you find important decide that.

And because I am writing this from the VB.language group I did make the
comparising with a natural language like English.

Note that no-one in this thread (that I'd seen before reading this
post, at least) has claimed that C# is absolutely better in all ways
than VB.NET - only that in *this* case, it's a flaw in VB.NET.

In my view natural language has nothing to do with it - a type should
be seen as very distinct from an *instance* of the type, but VB.NET is
allowing you to be misled. Why do you think that is an advantage?

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

[Cor]

Hi Jon,

I did not say it is an advantage, I disagree that it is a disadvantage.

In VB.net you can use more different methods/functions (whatever) to do the
same thing if you want that.

But that is maybe exactly the difference between the people who use the
language.

I have the idea, that for C# people often everything has to be direct
visible in true or false.

(What by the way I always say it the basic of programming, but that is
another discussion).

Cor

In my view natural language has nothing to do with it - a type should
be seen as very distinct from an *instance* of the type, but VB.NET is
allowing you to be misled. Why do you think that is an advantage?

[Jon Skeet [C# MVP]]

Cor <no*@non.com> wrote:

I did not say it is an advantage, I disagree that it is a disadvantage.

In VB.net you can use more different methods/functions (whatever) to do the
same thing if you want that.
Having multiple ways of doing the same thing is fine. However, in this
case you can mislead yourself into thinking that something is an
instance member when it's a static member. How can that *not* be a bad
thing? Do you not think that code which is misleading is bad? Isn't it
a good idea for the compiler to make sure you don't mislead people
wherever it can?
But that is maybe exactly the difference between the people who use the
language.

I have the idea, that for C# people often everything has to be direct
visible in true or false.
It really *is* black and white in this case - a static member simply
*isn't* an instance member. Why do you want to hide that information
from programmers, possibly leading to confusion?

If you don't believe it leads to confusion, do a Google search for
"Thread.current Thread().sleep" . Look at how many people have been
confused into thinking that Thread.sleep() is an instance method in
Java when it's not. If they ever try to call sleep "on" a different
thread, they're going to spend ages trying to work out why it's not
working as they expect it to. How can that be anything other than a bad
thing?
(What by the way I always say it the basic of programming, but that is
another discussion).

I'm afraid I didn't understand that sentence.

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

[Cor]

Hi Jon,

We will not agree now. However, in past I had the same idea as you.

However, VB.net has the strange thing, that it is the first programming
language that I have seen, which real acts in some degree as natural
languages, I like that.

Disadvantage is than that it has the same as every natural language, it can
be good or bad used, and therefore it can give a lot of misunderstandin g.

But that is always with words you saw it, I wrote

(What by the way I always say it the basic of programming, but that is
another discussion).
What is by the way, as I always say, the basic of programming, but that is
another discussion

(That was about true and false)
Cor

[Jon Skeet [C# MVP]]

Cor <no*@non.com> wrote:

We will not agree now. However, in past I had the same idea as you.

However, VB.net has the strange thing, that it is the first programming
language that I have seen, which real acts in some degree as natural
languages, I like that.
And how would that be damaged by including the same restriction that C#
has about accessing static members?
Disadvantage is than that it has the same as every natural language, it can
be good or bad used, and therefore it can give a lot of misunderstandin g.
You said before that you didn't believe there was an advantage, but
that you also didn't believe there was not an advantage.

Did you do the Google search I suggested in the previous post? If so,
do you not agree that there are many people using Thread.sleep
inappropriately ? If you agree with that, do you not agree that they are
confused? If you agree with that, do you not agree that their being
confused is a bad thing? If you agree with that, do you not agree that
they would not be confused if Java had the same restriction as C# does?
If you agree with that, how can you *not* agree that it's a
disadvantage?

Confusion is a bad thing. A "feature" which promotes confusion is a
disadvantage, in my view. Which part of that do you disagree with?
But that is always with words you saw it, I wrote

(What by the way I always say it the basic of programming, but that is
another discussion).
What is by the way, as I always say, the basic of programming, but that is
another discussion

(That was about true and false)

I still don't understand you. If your point is meant to be that natural
language can easily be misunderstood, then it's certainly true - think
of C# as a language which helps to make sure that your use of language
is easily understood, and VB.NET (in this case) as a language which
allows the above. Now consider that I can't understand what you wrote
above - why is that a *good* thing in your view?

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

[Cor]

Hi Jon,

If your point is meant to be that natural
language can easily be misunderstood, then it's certainly true - think
of C# as a language which helps to make sure that your use of language
is easily understood, and VB.NET (in this case) as a language which
allows the above.
C# is not a langueage that is easily understood because it cannot be
misunderstood.
(I think that you mix up true and false with the wrong references)
Now consider that I can't understand what you wrote
above - why is that a *good* thing in your view?

A natural language needs less comments in the program language and that I
find a very *good* thing.
(Comments are often very bad because they are not checked by rules)

Cor

[Jon Skeet [C# MVP]]

Cor <no*@non.com> wrote:

If your point is meant to be that natural
language can easily be misunderstood, then it's certainly true - think
of C# as a language which helps to make sure that your use of language
is easily understood, and VB.NET (in this case) as a language which
allows the above.
C# is not a langueage that is easily understood because it cannot be
misunderstood.

It is, partly - and it is in this case. The fact that you can't access
static members as if they were instance members means people won't
misunderstand and think they are using instance members.
(I think that you mix up true and false with the wrong references)

Again, please explain what you mean, very carefully. Where did "true"
and "false" come in here? (This thread demonstrates how easily natural
language can become confusing when it's not used carefully.)

Now consider that I can't understand what you wrote
above - why is that a *good* thing in your view?

A natural language needs less comments in the program language and that I
find a very *good* thing.
(Comments are often very bad because they are not checked by rules)

You've completely side-stepped all my points yet again, I notice. Once
more, which of the following do you disagree with?

1) Many people using Java write Thread.currentT hread().sleep(. ..)
instead of Thread.sleep(.. .)
2) Point 1) indicates a lack of understanding
3) This lack of understanding would not occur in C#, as it would be
invalid code - the programmers would *have* to realise that sleep
is a static method.
4) Confusion between static and instance members can lead to bugs in
code.
5) Bugs are bad, therefore anything which promotes confusion is bad.
6) Being able to access static members as if they were instance members
leads to confusion (points 1-3), and is therefore bad.

*Please* address the above - there's no point in having a discussion if
you're going to ignore the arguments you find difficult to refute.

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