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.WriteLine(ABC.MyInt);
ABC a;
Console.WriteLine(a.MyInt); //ERROR
a = new ABC();
Console.WriteLine(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.WriteLine(XYZ.MyInt)
Dim x As XYZ
Console.WriteLine(x.MyInt)
x = New XYZ()
Console.WriteLine(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

[Morten Wennevik]

Probably to make it less confusing. A static variable doesn't belong to
any instance, but rather to the class.
I think VB.Net does some things differently because it needs to be like VB
whereas C# was designed for .Net Framework?
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Jon Skeet [C# MVP]]

Mark <ma**@discussions.microsoft.com> wrote:

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.

Why do you think you *should* be able to access a static property via
an instance variable?

It makes it look like the property is an instance property, so would
possibly confuse the reader. This is one problem with Java, IMO - and
it's led a lot of people to write silly code like:

Thread.currentThread().sleep(5000);

when they really mean

Thread.sleep(5000);

- but the first version makes it look like you could call sleep() on a
particular thread to send it to sleep.

Basically I view this as a flaw in VB.NET, not in C#.

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

[Herfried K. Wagner [MVP]]

* Morten Wennevik <Mo************@hotmail.com> scripsit:

Probably to make it less confusing. A static variable doesn't belong
to any instance, but rather to the class.

In VB.NET, a static variable belongs to /all/ instances ('Shared').
That's semantically a difference.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Herfried K. Wagner [MVP]]

* "Mark" <ma**@discussions.microsoft.com> scripsit:

In C# I am not able to access a static property by an
instance variable, but in VB I can do it easily.

Yes -- a "limitation" in C#. It's intended to aviod programming errors
and make it easier to distinct between a call to a shared method and a
call to an instance method.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[One Handed Man [ OHM# ]]

Morton, what you have written is fundementally wrong.

VB.NET and C# are *BOTH* written for the .NET Framework.

The problem here is that Static members in C# are prevented from being
called through an instance of the class they are members of. This *ought*
to be the case for VB.NET as well in my opinion.

What John Skeet said was absolutely correct. In VB.NET you can do this

Dim a As Char = '1'
a.IsDigit(a)
or
Char.IsDigit(a)
In C# you 'Must' do this
char.IsDigit( . . . )

Making it far more readable IMHO.

Regards - OHM

Morten Wennevik wrote:

Probably to make it less confusing. A static variable doesn't belong
to any instance, but rather to the class.
I think VB.Net does some things differently because it needs to be
like VB whereas C# was designed for .Net Framework?

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[One Handed Man [ OHM# ]]

I would check the MSIL if I were you.

Regards - OHM

Herfried K. Wagner [MVP] wrote:

* Morten Wennevik <Mo************@hotmail.com> scripsit:

Probably to make it less confusing. A static variable doesn't belong
to any instance, but rather to the class.

In VB.NET, a static variable belongs to /all/ instances ('Shared').
That's semantically a difference.

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[One Handed Man [ OHM# ]]

The issue here is that Static members in C# are prevented from being
called through an instance of the class they are members of. This ought
to be the case for VB.NET as well in my opinion.

What John Skeet said was absolutely correct. In VB.NET you can do this

Dim a As Char = '1'
a.IsDigit(a)
or
Char.IsDigit(a)
In C# you 'Must' do this
char.IsDigit( . . . )

Making it far more readable IMHO.

Regards - OHM

[Herfried K. Wagner [MVP]]

* "One Handed Man [ OHM# ]" <O_H_M{at}BTInternet{dot}com> scripsit:

I would check the MSIL if I were you.

MSIL doesn't matter in this case. It's the semantic of 'Shared' which
tells the programmer that the member is shared between all instances.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Morten Wennevik]

I stand corrected, VB.NET is of course written for .Net Framework

My point is that VB.NET is a conversion of VB to make it "for .Net
Framework" (Like J#, which could be called "Java.Net")

C# however has no non framework counterpart and where VB.NET can't stray
too far from the original VB the designers of C# were free to make a
programming language tailored for .Net framework, while also getting rid
of many uncertainties found in C/C++ VB and Java.

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[One Handed Man [ OHM# ]]

What I am driving at is that the net effect is the same. The method of
getting at the (Static/Shared) member may be vary but there is only ONE
copy.

'Shared' is the right word when accessing the member through more than one
instance. However, the member is still 'Static' and can be accessed through
the Class definition because thats where it lives.

VB.NET extends the C# and C++ exposure by allowing ( wrongly ) in my humble
opinion, the exposure through an instance. I make it a point never to access
a shared member through an instance because, someone may revoke the current
flexibility at some later date, and I dont want to retro-change my code.

Regards - OHM

Herfried K. Wagner [MVP] wrote:

* "One Handed Man [ OHM# ]" <O_H_M{at}BTInternet{dot}com> scripsit:

I would check the MSIL if I were you.

MSIL doesn't matter in this case. It's the semantic of 'Shared' which
tells the programmer that the member is shared between all instances.

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[One Handed Man [ OHM# ]]

My point is that VB.NET is a conversion of VB to make it "for .Net
Framework" (Like J#, which could be called "Java.Net") J# was never intended to be a serious tool for development in .NET in my
opinion. It was simply a way to leverage brand J into NET world after all
that nasty business with Sun. I also think it would be more correct to say
that VB.NET was re-written rather than converted.
C# however has no non framework counterpart and where VB.NET can't
stray too far from the original VB the designers of C# were free to
make a programming language tailored for .Net framework, while also
getting rid of many uncertainties found in C/C++ VB and Java.

C# does not derive from a single not net base. I think if you look at it
it looks like some of the best of Java and C++
--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Cor]

Hi OHM,

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.

Just my thought.

Cor

[Jon Skeet [C# MVP]]

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
SomeVeryLongIndeedAndAnnoyingToReadTypeName.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.)

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

[One Handed Man [ OHM# ]]

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
SomeVeryLongIndeedAndAnnoyingToReadTypeName.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.)

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Armin Zingler]

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb

Mark <ma**@discussions.microsoft.com> wrote:

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.

Why do you think you *should* be able to access a static property via
an instance variable?

I don't think Mark wants the member to be accessible via a variable. He just
wanted to know why there is a difference. IMHO.

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Armin Zingler]

"Morten Wennevik" <Mo************@hotmail.com> schrieb

I stand corrected, VB.NET is of course written for .Net Framework

My point is that VB.NET is a conversion of VB to make it "for .Net
Framework" (Like J#, which could be called "Java.Net")

Ask most VB6 programmers. They ask why VB.NET is so totally different from
VB6.

VB.NET is a completely new language. There are only very few things that
have been built-in for compatibility reasons - and some of these _can_ also
be useful, like Modules.

Concerning static members accessible by references: I'd suggest an option to
turn this off because it leads to confusion.

Ex:
pictuerbox1.image.fromfile(...)
question: "Why does the image not change?"

Or:
system.text.encoding.ascii.asciiencoding.getstring (...)

--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Armin Zingler]

"One Handed Man [ OHM# ]" <O_H_M{at}BTInternet{dot}com> schrieb

The issue here is that Static members in C# are prevented from
being called through an instance of the class they are members of.
This ought to be the case for VB.NET as well in my opinion.

ACK.
--
Armin

[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 "comfortable" 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
SomeVeryLongIndeedAndAnnoyingToReadTypeName.Meth od()

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.com>
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?

[Mark]

>> Why do you think you *should* be able to access a
static property via

an instance variable?

I don't think Mark wants the member to be accessible via a variable. He justwanted to know why there is a difference. IMHO.

You are right Armin, I want to know why there is
difference.
If VB .net is allowing to it, then it also means that MSIL
allow to do it, and on other hand its restriction (To
avoid errors as some people say) in C#. If it is going to
avoid errors, then why it is in VB .Net
Mark

[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.currentThread().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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Armin Zingler]

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb

a type should
be seen as very distinct from an *instance* of the type, but VB.NET
is

The only example that comes into my mind:

dim i as integer
msgbox i.maxvalue

displays the maximum value of i.

Or, in general, if a property has the same value for all instances, it could
make sense to access a shared/static member by a reference - still I
wouldn't allow it.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[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 misunderstanding.

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 misunderstanding.
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.com>
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.currentThread().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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor]

Hi Jon,

I am not talking about static, threads, access members etc.

I was writing about the behaviour of the VB.net language and that it is in
some cases very inconsistent.
That is the nature of this programming language.

I did it when I started it by comparising it with a natural language, which
has that also, and you did disagree that.

It looks for me if you try in this discussion to take a single element and
show that it is true or false and therefore everything is true of false.

However, in most cases things exist in big collections from elements which
can be true or false and the complex from it can again make something true
or false (but mostly much more subjective).

A language as VB.net has the advantage that it needs fewer comments than the
more mathematical languages, but the consequence from this is that it has as
disadvantage that it has inconsistency problems.

Therefore is changing one element the route to making from VB.net a language
like C#. What is for me not a good idea, as well as it is in my opinion not
a good idea to make from a language as C# a language like VB.net.

Cor

[Jon Skeet [C# MVP]]

Cor <no*@non.com> wrote:

I am not talking about static, threads, access members etc.
But that's what the thread is about. This thread is *not* about "VB.NET
is better than C#" or vice versa. It's discussing whether or not the
single language "feature" of VB.NET allowing static member access
through an instance is a good idea or not.
I was writing about the behaviour of the VB.net language and that it is in
some cases very inconsistent.
That is the nature of this programming language.

I did it when I started it by comparising it with a natural language, which
has that also, and you did disagree that.

It looks for me if you try in this discussion to take a single element and
show that it is true or false and therefore everything is true of false.
I wasn't trying to extrapolate from this one VB.NET "feature" to VB.NET
itself - and no-one else in this thread has, as far as I can see.
However, in most cases things exist in big collections from elements which
can be true or false and the complex from it can again make something true
or false (but mostly much more subjective).

A language as VB.net has the advantage that it needs fewer comments than the
more mathematical languages, but the consequence from this is that it has as
disadvantage that it has inconsistency problems.
I don't believe it *does* need fewer comments, actually, but that's a
different matter.
Therefore is changing one element the route to making from VB.net a language
like C#. What is for me not a good idea, as well as it is in my opinion not
a good idea to make from a language as C# a language like VB.net.

I haven't suggested any changes (in this thread) beyond the one under
discussion. Are you objecting to *any* changes in VB.NET which add to
its consistency, just in case any genuinely *useful* features get
changed at the same time? If so, I think that's a very illogical
position. Take each potential change on its own merits - in this case,
I don't believe there's *any* merit (other than possible backward
compatibility with previous versions of VB, which I addressed in
another post) in VB's behaviour.

It sounds like you're basically going to refute *any* criticism of
VB.NET, which makes this a pretty worthless discussion...

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

[Cor]

Hi Jon,

I almost would say we agree,

This is the sentence from OHM

The issue here is that Static members in C# are prevented from being
called through an instance of the class they are members of. This ought
to be the case for VB.NET as well in my opinion.
And the last sentence of that is what I disagree and made my sample of a
natural language.
It sounds like you're basically going to refute *any* criticism of
VB.NET, which makes this a pretty worthless discussion...

If you did read this thread well, you will see that I did do a lot of
critism on VB.Net in oposite to you about C#.

But my point is only that as in every language (natural and program) you
cannot easy skip used words or meanings. (methods, functions, operators)
When I see in the vb.language group the IIF operator I always get something
(I am not German but in the German language is a very good word for it)
Unheimis.

If you do not have very important things to opposite I suggest to make this
EOT, it past a long time ago his sence.

Cor

[One Handed Man [ OHM# ]]

Cor,
With the greatest respect . . .

You have not adequately answered all Jon's points. This is without
doubt a clear argument, with only one conclusion as I see it.

If you cant discuss point by point and come to a conclusion in each
case then you may as well both stop.

Regards - OHM


Cor wrote:

Hi Jon,

I am not talking about static, threads, access members etc.

I was writing about the behaviour of the VB.net language and that it
is in some cases very inconsistent.
That is the nature of this programming language.

I did it when I started it by comparising it with a natural language,
which has that also, and you did disagree that.

It looks for me if you try in this discussion to take a single
element and show that it is true or false and therefore everything is
true of false.

However, in most cases things exist in big collections from elements
which can be true or false and the complex from it can again make
something true or false (but mostly much more subjective).

A language as VB.net has the advantage that it needs fewer comments
than the more mathematical languages, but the consequence from this
is that it has as disadvantage that it has inconsistency problems.

Therefore is changing one element the route to making from VB.net a
language like C#. What is for me not a good idea, as well as it is in
my opinion not a good idea to make from a language as C# a language
like VB.net.

Cor

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Cor]

Hi OHM,

Because I do not disagree those points, I disagree that you have to make
changes in a language.

It is in my opinon it is the same as the fact that languages as
Java, C#, C++, Javascript, which all derive from C use the == operator,
while that can nowadays made easy optional and use simple the = when there
is no conflict. But it is a part of the the language and therefore you
should not do that.

And therefore I disagree that you have to change things in a language that
are part from it if they are not in conflict with themself. Nobody says that
you have to use it.

Cor.
"One Handed Man [ OHM# ]" <O_H_M{at}BTInternet{dot}com> schreef in bericht
news:%2****************@tk2msftngp13.phx.gbl...

Cor,
With the greatest respect . . .

You have not adequately answered all Jon's points. This is without
doubt a clear argument, with only one conclusion as I see it.

If you cant discuss point by point and come to a conclusion in each
case then you may as well both stop.

Regards - OHM


Cor wrote:

Hi Jon,

I am not talking about static, threads, access members etc.

I was writing about the behaviour of the VB.net language and that it
is in some cases very inconsistent.
That is the nature of this programming language.

I did it when I started it by comparising it with a natural language,
which has that also, and you did disagree that.

It looks for me if you try in this discussion to take a single
element and show that it is true or false and therefore everything is
true of false.

However, in most cases things exist in big collections from elements
which can be true or false and the complex from it can again make
something true or false (but mostly much more subjective).

A language as VB.net has the advantage that it needs fewer comments
than the more mathematical languages, but the consequence from this
is that it has as disadvantage that it has inconsistency problems.

Therefore is changing one element the route to making from VB.net a
language like C#. What is for me not a good idea, as well as it is in
my opinion not a good idea to make from a language as C# a language
like VB.net.

Cor

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Jon Skeet [C# MVP]]

Cor <no*@non.com> wrote:

Because I do not disagree those points, I disagree that you have to make
changes in a language.
So you agree that it *can* cause confusion and that confusion *is* a
bad thing? You agree that there is no advantage to having it, but there
*is* a disadvantage to having it?
It is in my opinon it is the same as the fact that languages as
Java, C#, C++, Javascript, which all derive from C use the == operator,
while that can nowadays made easy optional and use simple the = when there
is no conflict. But it is a part of the the language and therefore you
should not do that.
Separating == from = adds clarity - it makes it very easy to see the
difference between an assignment and a comparison. If there were two
different characters for the two different ideas, that would be even
better, IMO.
And therefore I disagree that you have to change things in a language that
are part from it if they are not in conflict with themself.
Even when there's a specific disadvantage, as I've already shown?
Nobody says that you have to use it.

No, but that doesn't mean that it's not worth having an opinion on how
it could be improved, or whether a language would be better off without
a certain feature even if it's not worth going as far as changing it
now.

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

[Cor]

Jon,

Do not put words in my mouth which I have never said, than I have to give a
reaction.

You agree that there is no advantage to having it, but there
*is* a disadvantage to having it?
No I noware said that, there is an advantage that is language consistenty in
time and that is the only argument I use in this to long thread.
Separating == from = adds clarity - it makes it very easy to see the
difference between an assignment and a comparison. If there were two
different characters for the two different ideas, that would be even
better, IMO.

Your opinion and mine about this are different. I am using Arabic characters
for values, Latin for the alphabeth and I thought Greeck for operators. I
have no need for the new Calfornian ones. But that is not important.

Nobody says that you have to use it.

No, but that doesn't mean that it's not worth having an opinion on how
it could be improved, or whether a language would be better off without
a certain feature even if it's not worth going as far as changing it
now.

My opinion is that arguing about this kind of things is the first step to
improvement.

Cor

[Jon Skeet [C# MVP]]

Cor <no*@non.com> wrote:

Do not put words in my mouth which I have never said, than I have to give a
reaction.
I don't believe I did, actually.

You agree that there is no advantage to having it, but there
*is* a disadvantage to having it?

No I noware said that

You said that you hadn't argued my points because you didn't disagree with them.
So, do you disagree with my points or not? If you do, please give your
reasons (which you've studiously avoided doing so far).
there is an advantage that is language consistenty in
time and that is the only argument I use in this to long thread.

That's an argument in favour of not *changing* VB.NET. It's not an
argument against the opinion that it's a "disadvantage" and a flaw in
VB.NET compared with C#'s handling of the same issue.

Separating == from = adds clarity - it makes it very easy to see the
difference between an assignment and a comparison. If there were two
different characters for the two different ideas, that would be even
better, IMO.

Your opinion and mine about this are different. I am using Arabic characters
for values, Latin for the alphabeth and I thought Greeck for operators. I
have no need for the new Calfornian ones. But that is not important.

I haven't suggested introducing any - I'm just saying that in a
parallel universe where we had such characters, that would be a better
state of affairs. As we don't, I'd rather have == and = than combine
the two concepts into one symbol.

Nobody says that you have to use it.

No, but that doesn't mean that it's not worth having an opinion on how
it could be improved, or whether a language would be better off without
a certain feature even if it's not worth going as far as changing it
now.

My opinion is that arguing about this kind of things is the first step to
improvement.

But you seem to be suggesting that nothing should be changed as that
would alter the ethos of the language. In particular:

<quote>
Therefore is changing one element the route to making from VB.net a
language like C#. What is for me not a good idea, as well as it is in
my opinion not a good idea to make from a language as C# a language
like VB.net.
</quote>

There are two separate issues here:

1) Is VB.NET's handling of static members flawed?
2) Is the pain of changing it worth the benefit?

I believe the answer to question 1 is a definite "yes!". I believe the
answer to question 2 is much harder to determine, and is much more
reasonable for there to be disagreements about. So far you haven't
argued question 1 at all as far as I've seen, whereas it's been the
main point I've been addressing.

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

[One Handed Man [ OHM# ]]

There is a difference between argument and discussion. Arguments by
definition are differences of opinion which may or may not result in an
agreement. Discussions tend to be less heated ( unlike this one - which is
more of an argument ), and more often result in some kind of resolution

I suppose you may prefer accessing a shared member via an instance, and you
may not even know why you prefer it. However, I think if each point were
discussed in detail then a weighted conclusion would be agreed upon.

IMHO, Jon has already put forward a good case for *not* allowing access via
an instance. I have yet to see you put forward a cogent response *for
allowing it*.
Regards - OHM


Cor wrote:

Jon,

Do not put words in my mouth which I have never said, than I have to
give a reaction.

You agree that there is no advantage to having it, but there
*is* a disadvantage to having it?

No I noware said that, there is an advantage that is language
consistenty in time and that is the only argument I use in this to
long thread.

Separating == from = adds clarity - it makes it very easy to see the
difference between an assignment and a comparison. If there were two
different characters for the two different ideas, that would be even
better, IMO.

Your opinion and mine about this are different. I am using Arabic
characters for values, Latin for the alphabeth and I thought Greeck
for operators. I have no need for the new Calfornian ones. But that
is not important.

Nobody says that you have to use it.

No, but that doesn't mean that it's not worth having an opinion on
how it could be improved, or whether a language would be better off
without a certain feature even if it's not worth going as far as
changing it now.

My opinion is that arguing about this kind of things is the first
step to improvement.

Cor

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Cor]

OHM,

I hate it if people are telling that I said things which I never said.

I have only said that I disagree with the idea changing a program language
for a in my eyes seldom used situation.

There are people who want people not allow to drive in a car because that
can give accidents, do you want me to tell why I will allow to drive in a
car while I know it gives accidents. Altough accidents are not seldom.

What am I doing answering this kind of rubish arguing.

Cor

[scorpion53061]

Hi All,

Is it possible this conversation has run its course and it may be time to
move on?

[One Handed Man [ OHM# ]]

Hi Cor,

No disrespect meant.

I didnt say that you said "anything". What I did say was that
you didnt give a cogent argument for this functionality. And
as far as I see it, you have not.

Regards - OHM

Cor wrote:

OHM,

I hate it if people are telling that I said things which I never said.

I have only said that I disagree with the idea changing a program
language for a in my eyes seldom used situation.

There are people who want people not allow to drive in a car because
that can give accidents, do you want me to tell why I will allow to
drive in a car while I know it gives accidents. Altough accidents are
not seldom.

What am I doing answering this kind of rubish arguing.

Cor

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Tom Leylan]

don't be so picky... Don and Cor both know what each other meant...

you see how annoying your messages can be :-)
"One Handed Man [ OHM# ]" <O_H_M{at}BTInternet{dot}com> wrote in message
news:e0****************@TK2MSFTNGP11.phx.gbl...

There is a difference between argument and discussion. Arguments by
definition are differences of opinion which may or may not result in an
agreement. Discussions tend to be less heated ( unlike this one - which is
more of an argument ), and more often result in some kind of resolution

I suppose you may prefer accessing a shared member via an instance, and you may not even know why you prefer it. However, I think if each point were
discussed in detail then a weighted conclusion would be agreed upon.

IMHO, Jon has already put forward a good case for *not* allowing access via an instance. I have yet to see you put forward a cogent response *for
allowing it*.
Regards - OHM


Cor wrote:

Jon,

Do not put words in my mouth which I have never said, than I have to
give a reaction.

You agree that there is no advantage to having it, but there
*is* a disadvantage to having it?

No I noware said that, there is an advantage that is language
consistenty in time and that is the only argument I use in this to
long thread.

Separating == from = adds clarity - it makes it very easy to see the
difference between an assignment and a comparison. If there were two
different characters for the two different ideas, that would be even
better, IMO.

Your opinion and mine about this are different. I am using Arabic
characters for values, Latin for the alphabeth and I thought Greeck
for operators. I have no need for the new Calfornian ones. But that
is not important.

Nobody says that you have to use it.

No, but that doesn't mean that it's not worth having an opinion on
how it could be improved, or whether a language would be better off
without a certain feature even if it's not worth going as far as
changing it now.

My opinion is that arguing about this kind of things is the first
step to improvement.

Cor

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Cor]

OHM,

I thought that I even saw it yesterday in a message thread and it did cost
me some extra time to understand the code. (To be true I did only slightly
look at what you where talking about, because I did agree with the
arguments).

But I only agree that it should not be used

When I saw that you said "prevented from" than I did disagree and I did not
use more arguments in this long thread.

Because I find it one of the charms from VB.net that it gives such a lot of
personal responsibility.

We both live in the EU which gives us responsibility. But there are more
countries in the world and in that countries is another behaviour and
therefore I am glad that I am from the EU and will defend that also.

Cor

..

[Herfried K. Wagner [MVP]]

* Jon Skeet [C# MVP] <sk***@pobox.com> scripsit:

Java, C#, C++, Javascript, which all derive from C use the == operator,
while that can nowadays made easy optional and use simple the = when there
is no conflict. But it is a part of the the language and therefore you
should not do that.

Separating == from = adds clarity - it makes it very easy to see the
difference between an assignment and a comparison. If there were two
different characters for the two different ideas, that would be even
better, IMO.

Mhm... I /never/ had a problem with the overloaded '=' operator in
BASIC/VB/VB.NET. I don't think that a lot of people had problems with
that and/or wrote "buggy" code because of the two meanings of '='.

Just my 2 Euro-cents.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Herfried K. Wagner [MVP]]

* "Cor" <no*@non.com> scripsit:

I have only said that I disagree with the idea changing a program language
for a in my eyes seldom used situation.
Full ACK. If it's a problem, the real problem -- the programmer sitting
in front of the computer -- should be changed. Not the flexible
programming language.
There are people who want people not allow to drive in a car because that
can give accidents, do you want me to tell why I will allow to drive in a
car while I know it gives accidents. Altough accidents are not seldom.

Full ACK.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Herfried K. Wagner [MVP]]

* Jon Skeet [C# MVP] <sk***@pobox.com> scripsit:

I am not talking about static, threads, access members etc.

But that's what the thread is about. This thread is *not* about "VB.NET
is better than C#" or vice versa. It's discussing whether or not the
single language "feature" of VB.NET allowing static member access
through an instance is a good idea or not.

As a VB.NET programmer, I think it's a good idea. That's my subjective
optinion, I know. And I am not able to clearly state /why/ it's my
opinion. But that doesn't matter.

A diskussion based on "facts" doesn't make sense (IMO) in this case.

It looks for me if you try in this discussion to take a single element and
show that it is true or false and therefore everything is true of false.

I wasn't trying to extrapolate from this one VB.NET "feature" to VB.NET
itself - and no-one else in this thread has, as far as I can see.

Mhm... IMO it's only possible to understand /why/ a particular feature
is part of the programming language when having a look at the whole
programming language and the motivations and paradigms behind it.
VB.NET provides code-based RAD, by allowing to call a shared member by
an instance (which is semantically correct in VB.NET because of the
changed meaning ("static" -> "shared") it makes programming easier.
It's a shortcut. Maybe a dirty shortcut. Who cares?

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Tom Leylan]

Herfried,

Jon appears to be trying to educate people by mentioning a known fact. The
overloaded = operator is "known" to be a source of problems. This doesn't
mean that you ever once made the error (of course not) but when language
developers surveyed language users it turned out it was a source of errors.

But if it has never been a source of confusion why do you imagine that the
language developers separated them? Nothing else to do?
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote...

* Jon Skeet [C# MVP] <sk***@pobox.com> scripsit:

Java, C#, C++, Javascript, which all derive from C use the == operator,
while that can nowadays made easy optional and use simple the = when there is no conflict. But it is a part of the the language and therefore you
should not do that.

Separating == from = adds clarity - it makes it very easy to see the
difference between an assignment and a comparison. If there were two
different characters for the two different ideas, that would be even
better, IMO.

Mhm... I /never/ had a problem with the overloaded '=' operator in
BASIC/VB/VB.NET. I don't think that a lot of people had problems with
that and/or wrote "buggy" code because of the two meanings of '='.

[One Handed Man [ OHM# ]]

Tut, Tut, your being so trite.

:))

OHM

Tom Leylan wrote:

don't be so picky... Don and Cor both know what each other meant...

you see how annoying your messages can be :-)
"One Handed Man [ OHM# ]" <O_H_M{at}BTInternet{dot}com> wrote in
message news:e0****************@TK2MSFTNGP11.phx.gbl...

There is a difference between argument and discussion. Arguments by
definition are differences of opinion which may or may not result in
an agreement. Discussions tend to be less heated ( unlike this one -
which is more of an argument ), and more often result in some kind
of resolution

I suppose you may prefer accessing a shared member via an instance,
and you may not even know why you prefer it. However, I think if
each point were discussed in detail then a weighted conclusion would
be agreed upon.

IMHO, Jon has already put forward a good case for *not* allowing
access via an instance. I have yet to see you put forward a cogent
response *for allowing it*.
Regards - OHM


Cor wrote:

Jon,

Do not put words in my mouth which I have never said, than I have to
give a reaction.

You agree that there is no advantage to having it, but there
*is* a disadvantage to having it?

No I noware said that, there is an advantage that is language
consistenty in time and that is the only argument I use in this to
long thread.

Separating == from = adds clarity - it makes it very easy to see
the difference between an assignment and a comparison. If there
were two different characters for the two different ideas, that
would be even better, IMO.

Your opinion and mine about this are different. I am using Arabic
characters for values, Latin for the alphabeth and I thought Greeck
for operators. I have no need for the new Calfornian ones. But that
is not important.

> Nobody says that you have to use it.

No, but that doesn't mean that it's not worth having an opinion on
how it could be improved, or whether a language would be better off
without a certain feature even if it's not worth going as far as
changing it now.

My opinion is that arguing about this kind of things is the first
step to improvement.

Cor

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Herfried K. Wagner [MVP]]

* "Tom Leylan" <ge*@iamtiredofspam.com> scripsit:

Jon appears to be trying to educate people by mentioning a known fact. The
overloaded = operator is "known" to be a source of problems. This doesn't
mean that you ever once made the error (of course not) but when language
developers surveyed language users it turned out it was a source of errors.
"known fact"... Driving a car can cause an accident. That's a known
fact too. Nevertheless, it doesn't make sense to forbid driving a car
and forcing people to use public transport systems instead. There are
lots of tools available in the world which make solving a problem easier
-- sometimes they have certain disadvantages if the person who uses them
isn't able to use them.
But if it has never been a source of confusion why do you imagine that the
language developers separated them? Nothing else to do?

Mhm... They wanted to make a useless separation in order to make their
work easier.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>