Static Members

[Cor]

OHM,

See my comment at Jon.

Cor

 

[Jon Skeet [C# MVP]]

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?

 

[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

 

[Mark]

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

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.

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]]

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.

 

[Armin Zingler]

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.

 

[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]]

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?

 

[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]]

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

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.

 

[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]]

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

 

[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]

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.

 

[Jon Skeet [C# MVP]]

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.

 

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

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]]

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.

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.

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.

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.

 

[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]

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