C# is too nitpicky?

  • Thread starter Thread starter VeebeeGeeBees
  • Start date Start date
V

VeebeeGeeBees

Why is it that you can do this in VB.net but not (the syntactical
equivilent of it in) C#?:

Dim m as MessageBox
m.Show("hello")
 
Why is it that you can do this in VB.net but not (the syntactical
equivilent of it in) C#?:

Dim m as MessageBox
m.Show("hello")
Click to expand...

Because VB.NET is too lax... MessageBox.Show is a shared member (static
in C#). That means it is not associated with any particular instance of
a class, but with the class it's self. The effect is that it is
unnecessary to create an instance (use new) to invoke a static member.
In C#, they correctly make this distinction by not allowing you to call
static members through instances of the object. I think this is good,
because it makes the code more explicit. The VB.NET way is sloppy in my
honest oppinion and can make the code harder to read since you can never
be sure if the method invoked is shared or not.
 
Because VB.NET is too lax... MessageBox.Show is a shared member (static
in C#). That means it is not associated with any particular instance of
a class, but with the class it's self. The effect is that it is
unnecessary to create an instance (use new) to invoke a static member.
In C#, they correctly make this distinction by not allowing you to call
static members through instances of the object. I think this is good,
because it makes the code more explicit. The VB.NET way is sloppy in my
honest oppinion and can make the code harder to read since you can never
be sure if the method invoked is shared or not.
Click to expand...

Well its not a good thing when all of the Dot Net documentation leads
you to believe that Shared in VB.Net is the same as static in C#, when
in reality they behave differently. Being able to instantiate a new
var of type MessageBox is more in like with "purist" OOP. C# seems to
want to carry forward the poorly implemented OOP features of C++.
 
Tom, I'm pretty new but how is that different then say
dim x as string
x.toUpper

are you saying you can't do that in C#?

can't we tell that it's a shared class because of the absence of the New
constructor?

You're right that it's sometimes hard to read WRT reading if the method was
shared or not.






 
It leads you to believe this, because it is true - they are the same.

C# imposes a restriction, where you cannot use an instance to have access to
a static member. VB has no such restriction and allows you to do it either
way.

 
Tom, I'm pretty new but how is that different then say
dim x as string
x.toUpper

are you saying you can't do that in C#?
Click to expand...

ToUpper is not a static method. It is an instance method. So you have
to create an instance of a string.

string s = "hello, world";
Console.WriteLine(s.ToUpper());
can't we tell that it's a shared class because of the absence of the New
constructor?
Click to expand...

When looking at a line of code, it is not always convienient to go look
at the declaration.
 
It leads you to believe this, because it is true - they are the same.

C# imposes a restriction, where you cannot use an instance to have access to
a static member. VB has no such restriction and allows you to do it either
way.
Click to expand...
How can you say they are the same then say they are different,
separated only by a line break?
 
Well its not a good thing when all of the Dot Net documentation leads
you to believe that Shared in VB.Net is the same as static in C#, when
in reality they behave differently. Being able to instantiate a new
var of type MessageBox is more in like with "purist" OOP. C# seems to
want to carry forward the poorly implemented OOP features of C++.
Click to expand...

Shared and static are essenitally the same thing. It's just that the
VB.NET compiler does not enforce the difference's properly, IMHO. Of
course that is by design - but a bad one. The point is that a static
member is not associated with any single instance of a class. So, it
makes little sense to allow the calling of these methods through and
instance. In this instance, C# get's it right. YMMV.
 
The meaning of the keyword is the same.

It is only a matter of how the language let's you use it.

If you write a static method in C#, and try to use it from C#, it wil force
you to use the type name. If you use the same method from VB (original
method still written in C#), you can do it either way.

If you then rewrite the method as a shared method in VB, and try to use it
from VB, VB will let you do it either way. Try using that VB shared method
from C# - and you have the restriction again.

So in the end, no matter if you write it in C# and use 'static', or in VB
and use 'Shared', the meaning is the same. C# will always impose the
restriction no matter which language it was written in - and VB will not.
That is the whole point.
 
How can you say they are the same then say they are different,
separated only by a line break?
Click to expand...

They are the same at the class level - it's just that the VB.NET
compiler does not enforce the distinction between shared and instance
members. Which is bad, IMHO.
 
They are the same at the class level - it's just that the VB.NET
compiler does not enforce the distinction between shared and instance
members. Which is bad, IMHO.
Click to expand...

Actually I just realized whats going on is not what you guys are
saying.

Try this:

Dim x as MessageBox
Dim y as MessageBox

' Note you cannot instantiate a new
' one due to private constructor

x.Show("test")
y.Show(Cbool(x is y))


x and y refer to same instance ("true" is displayed on the second
line).
Without the first line you cannot compare x to y because they are not
yet set to the "global" static messagebox.

in VB.net, it appears that Shared gives you THE OPTION of calling a
method without instantiating an instance... but you can do so if you
want.

in C#, static means you MUST call the method without declaring an
instance.

Big difference.

My guess is that this is a language design flaw.. not really a flaw in
C# or VB.Net, but a flaw in the sense that the design team strived to
maintain the behavior people were used to in earlier versions of those
languages (VB6 and C++), thus the difference in behavior.

If you need proof, create a new vb class with a simple shared sub, try
instantiating an x and y variable. You can do so, and the test to see
if x = y above will return false because they are not the same, like
the case of the global MessageBox class.

My question now is why is the MessageBox class "system global" so to
speak, whereas the class created in VB.net is not?
 
* Tom Shelton said:
Because VB.NET is too lax... MessageBox.Show is a shared member (static
in C#). That means it is not associated with any particular instance of
a class, but with the class it's self. The effect is that it is
Click to expand...

Basically I agree, but if you have a look at the keyword 'Shared' which
is used for static members. Shared members are semantically /shared/
between /all/ instances of a class. That's why accessing shared members
by using an instance variable IMO makes sense for VB.NET.
because it makes the code more explicit. The VB.NET way is sloppy in my
honest oppinion and can make the code harder to read since you can never
be sure if the method invoked is shared or not.
Click to expand...

I agree too but then 'Shared' is IMO not the right term for a keyword
that marks static members :-).
 
* Tom Shelton said:
The point is that a static member is not associated with any
single instance of a class.
Click to expand...

It's shared between /all/ instances, so callong these methods through an
instance makes sense (IMO).

Just my 2 cents.
 
* VeebeeGeeBees said:
My question now is why is the MessageBox class "system global" so to
speak, whereas the class created in VB.net is not?
Click to expand...

What do you mean by "system global"?
 
It's shared between /all/ instances, so callong these methods through an
instance makes sense (IMO).

Just my 2 cents.
Click to expand...

Well, I guess this is a topic that everyone is going to have their
personall preference about... I find the VB way to be unintuitive and
wrong.
 
Actually I just realized whats going on is not what you guys are
saying.
Click to expand...

Yes it is...
Try this:

Dim x as MessageBox
Dim y as MessageBox

' Note you cannot instantiate a new
' one due to private constructor
Click to expand...

Yep... You can not create an instance of messagebox at all.
x.Show("test")
y.Show(Cbool(x is y))


x and y refer to same instance ("true" is displayed on the second
line).
Without the first line you cannot compare x to y because they are not
yet set to the "global" static messagebox.
Click to expand...

There is no global static message box. There is no instance of
messagebox. Both x and y will remain nothing.

If x is nothing then
x.show("Nothing")
end if

This is essentially a class like this in C#:

public class MessageBox : .....
{
private MessageBox() {}

public static Windows.Forms.DialogResult Show(....)
{
...
}
}

in VB.net, it appears that Shared gives you THE OPTION of calling a
method without instantiating an instance... but you can do so if you
want.

in C#, static means you MUST call the method without declaring an
instance.

Big difference.
Click to expand...

Exactly. But it isn't a difference on the IL level. It is a difference
on the language level.
My guess is that this is a language design flaw.. not really a flaw in
C# or VB.Net, but a flaw in the sense that the design team strived to
maintain the behavior people were used to in earlier versions of those
languages (VB6 and C++), thus the difference in behavior.
Click to expand...

As you say, it is a bow to langauge compatability. A bad one, but one
none the less.
If you need proof, create a new vb class with a simple shared sub, try
instantiating an x and y variable. You can do so, and the test to see
if x = y above will return false because they are not the same, like
the case of the global MessageBox class.
Click to expand...

The reason that MessageBox return true is because you are comparing two
variables that are both nothing - and nothin is nothing.
My question now is why is the MessageBox class "system global" so to
speak, whereas the class created in VB.net is not?
Click to expand...

There is no instance of MessageBox. Only static methods. Make your
constructor private so that you can't create an instance and you will
have the same effect...

public class TestClass
private Sub new()
end sub

public shared sub TestMethod()
Console.WriteLine("Hello")
end sub
end class

public sub main()
dim a as testclass
dim b as testclass

testclass.testmethod()
a.testmethod
b.testmethod


if a is b then
Console.writeline("a is b")
end if

if a is nothing then
console.writeline("a is nothing")
end if

if b is nothing then
console.writeline("b is nothing")
end if

if typeof a is testclass then
console.writeline("this will never happen")
end if
End sub
 
Back
Top