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

[One Handed Man [ OHM# ]]

You too !

Herfried K. Wagner [MVP] wrote:

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

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Tom Leylan]

I was going to ask if you had ever taken a debate course but it's obvious
you haven't.

The concepts behind driving a car and the design of a language are
completely different. The similarity (if you insist on trying to draw
parallels) is that they have added all manner of safety features since the
car was invented for one reason "it was proven to be dangerous"... that's
why the cabs are largely crush-proof, there is firewall, seatbelts are
required, turn signals were added, the gasoline you can put in it is
regulated and oh, yeah... a license (and insurance) is required to operate
one.

And if you were to take even a casual stroll through a hardware store
"prior" to attempting to convince people through lame arguments you would
see that all of the tools you are talking about have safety features added.
They were added because people inadvertantly (through normal use) could hurt
themselves or others. I'm sure you were there to argue that there is no
reason for circuit breakers on electrical things... you've never had an
electrical short and burned your house down. The less intelligent masses
(the entire rest of the world, btw) however has concluded there is a good
reason to attempt to reduce the number of problems through careful design.

Mhm... They wanted to make a useless separation in order to make their
work easier.
Would you consider not being a complete ass?

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote... * "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>

[Herfried K. Wagner [MVP]]

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

You too !

You too (whatever you are referring to)!

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

[Herfried K. Wagner [MVP]]

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

The concepts behind driving a car and the design of a language are
completely different. The similarity (if you insist on trying to draw
I would say that both of them -- the programming language and the car --
are tools created to solve a "problem".
parallels) is that they have added all manner of safety features since the
car was invented for one reason "it was proven to be dangerous"... that's
why the cabs are largely crush-proof, there is firewall, seatbelts are
That's an interesting point.
required, turn signals were added, the gasoline you can put in it is
regulated and oh, yeah... a license (and insurance) is required to operate
one.
IMO there is still at least one big difference. I will explain my point
of view:

In VB.NET, and that's a difference to other programming languages,
static members are semantically not members which only belong to the
class and not to an instance, they are instead members which belong to
/all/ instances of a class. That's a big and IMO very fundamental
difference. Thus, it's incorrect to try to apply a point of view which
is common to other programming languages onto a different programming
language. Only because it's different, it's not bad. Only because
somebody is not familiar with something, and consequently doesn't know
how to use it, it's not bad (by definition).

I never saw a professional (I don't claim to be one) programmer making a
mistake because of this feature of VB.NET. If I saw code making use of
the feature /and/ working incorrect, I knew that the person who wrote it
was not a professional. I often see beginners using this feature in a
wrong way. Yes, that's a fact and it's sometimes annoying if you have
to explain to a beginner why he /should not/ use this feature unless he
is sure that he understood it.

It's a dangerous tool, nobody doubts that. But it's a useful tool.
And if you were to take even a casual stroll through a hardware store
"prior" to attempting to convince people through lame arguments you would
see that all of the tools you are talking about have safety features added.
..NET has its safety features added too. Visual Basic .NET has its
"safety" features too. And it has a box filled with advanced tools
which should not be used by beginners -- they are for use by "Gods"
only. I would not access a shared member by using an instance variable
(there are /some very rare cases/ in which I prefer to do that to avoid using
reflection), but I would not tell somebody to do that. Nevertheless, I
know that it's possible. I know why I don't use it. It's like a
weapon. It's something you must use carefully.
They were added because people inadvertantly (through normal use) could hurt
themselves or others.

Don't tell me that a professional programmer will access a shared member
through an instance member "accidentially". Maybe an option to hide
shared members when accessing properties/methods of an object in the
code editor would be fine.

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

[Tom Leylan]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote...

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

The concepts behind driving a car and the design of a language are
completely different. The similarity (if you insist on trying to draw
I would say that both of them -- the programming language and the car --
are tools created to solve a "problem".

They are also both composed of atoms... using a car as a metaphor for
computer programming doesn't work. They are trying to solve "different
problems" and with that comes a different set of criteria when weighing
alternative actions. You may as well argue that near lethal doses of
radiation should be given to "everybody" because "it can cure cancer in
some."
Only because it's different, it's not bad. Only because
somebody is not familiar with something, and consequently doesn't know
how to use it, it's not bad (by definition).
That's perfectly normal and nobody has suggested (ever) that "different is
bad." So you are correct. The thread clearly points out that "confusion"
exists. As a general rule language developers try to reduce confusion. I
note the following from a posting back in Sep. 2000...

<begin quote>
Another survey question for you all, if you are interested:

As you may know, in JScript.NET we have support for classes, including
static members. One thing that we (the ECMA committee) needs to decide is
whether static members can be seen from instances.
<end quote>

that demonstrates that the ECMA committee was at least "considering" whether
one methodology or another would be less confusing. Note that nowhere has
anybody suggested it should "be okay to be different" ... their concern was
(likely) not about the personal feelings of a single user but rather a large
sense of eliminating (as best one can) confusion about things that are
already confusing to many.
I never saw a professional (I don't claim to be one) programmer making a
mistake because of this feature of VB.NET. If I saw code making use of
the feature /and/ working incorrect, I knew that the person who wrote it
was not a professional. I often see beginners using this feature in a
wrong way. Yes, that's a fact and it's sometimes annoying if you have
to explain to a beginner why he /should not/ use this feature unless he
is sure that he understood it.
Whether you actually see something isn't the gauge is it? It isn't much of
a reach to "know" that programmer's do it. And it doesn't mean they aren't
professional. They might be sloppy or perhaps just careless... or it might
mean they just don't see the problem. You make it sound like programmers
come in two flavors. What if they have programmed incredible software for
years and yet reference the static variable this way? Are you going to
scream "hey you're not a professional" well no need to answer that I'm
certain I can guess :-)
It's a dangerous tool, nobody doubts that. But it's a useful tool.
It isn't particularly dangerous and it isn't particularly useful at all (or
perhaps you are describing something else.) Did you read the thread? It
used the word "confusing."
.NET has its safety features added too. Visual Basic .NET has its
"safety" features too. And it has a box filled with advanced tools
which should not be used by beginners -- they are for use by "Gods"
only.
Well I'll bite... which advanced tools should not be used by beginners? And
where do you administer the tests so they know when they use them? Again
(and always again Herfried (search any thread we have ever had)) you aren't
answering questions, you are defending an undefendable position you have
taken. Advanced tools (whatever your definition of that might be) aren't
"advanced" because they are especially dangerous. Gosh you yourself used a
car as an example... do you not consider that an advanced tool? Aren't cars
used by beginners? Aren't cars used by old folks, the nearly blind, the
habitually drunk, the teenager on a cell-phone? You want to prevent
somebody from using a datagrid or is the FTP component you think they need
special training on?
Don't tell me that a professional programmer will access a shared member
through an instance member "accidentially". Maybe an option to hide
shared members when accessing properties/methods of an object in the
code editor would be fine.

Well maybe you can get on the committee... you seem eminently qualified.
And oh gosh "professional programmer" never... that knowledge comes with the
gold patch that says "I'm a professional programmer" and then they take that
oath and stuff.

It's the semi-professional, quasi-professional, sub-professional, and
pseudo-professionals I spend my nights worrying about.... what on Earth are
you talking about? Have you ever ventured into a room with people in it?
Do you live in PerfectVille? Don't get down off that mountain, the world as
it is will scare you to death.

As always this has been a useless pursuit... you seem to care too much about
your perceived status as an expert to ever have a sane conversation.

[Cor]

Hi Tom,

Maybe I did see it wrong, but I did not use a car accident as a metaphor for
a program error.

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.

They are also both composed of atoms... using a car as a metaphor for
computer programming doesn't work.

I try only to tell that the accident itself had nothing to do in this
discussion.
The metaphor was if I should be the one who had to prove that there would
not be an accident, while that was not my point.

(And then in the methaphor every accident, not only the big ones you are
talking about)

In my opinion you did change very much my the words Tom.

Or are you talking about the continuation from Herfried?

Cor

[Herfried K. Wagner [MVP]]

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

Maybe I did see it wrong, but I did not use a car accident as a metaphor for
a program error.
Nobody did that. I only compared making a programming mistake because
of accesing a shared member through an instance variable with making a
car accident by misusing the car.
In my opinion you did change very much my the words Tom.

Or are you talking about the continuation from Herfried?

Sorry, I don't understand you again...

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

[Herfried K. Wagner [MVP]]

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

The concepts behind driving a car and the design of a language are
completely different. The similarity (if you insist on trying to draw
I would say that both of them -- the programming language and the car --
are tools created to solve a "problem".

They are also both composed of atoms... using a car as a metaphor for
computer programming doesn't work. They are trying to solve "different
problems" and with that comes a different set of criteria when weighing
alternative actions. You may as well argue that near lethal doses of
radiation should be given to "everybody" because "it can cure cancer in
some."

/You/ said that... I still don't get the point. Why not eliminate
recursion? It can cause stack overflows when used by people who don't
know how to properly use it. There are lots of other samples I can
think of which can cause errors by misusing them. That's not a reason
for forbidding them. Some tools should be used carefully, I already
said that.

Only because it's different, it's not bad. Only because
somebody is not familiar with something, and consequently doesn't know
how to use it, it's not bad (by definition).

That's perfectly normal and nobody has suggested (ever) that "different is
bad." So you are correct. The thread clearly points out that "confusion"
exists.

For /me/, this confusion never existed. I never used instance members
to access shared members. So it's not a problem for me. I don't have
any problem with the fact that this "feature" exists. If other people
have problems with it, they just should not use it. Removing a feature
only because its often misused is IMHO the wrong way.
As a general rule language developers try to reduce confusion. I
Who says that this "general rule" must apply to every programming
language? Is a programming language worse than an other if it breaks
the rule but consequently allows the programmer to be faster (or
whatever)? As a result, the programming language may not be perfect for
people who don't know how to use a tool carefully. Those who know how
to do that, will be more productive.
Another survey question for you all, if you are interested:

As you may know, in JScript.NET we have support for classes, including
static members. One thing that we (the ECMA committee) needs to decide is
whether static members can be seen from instances.
<end quote>
ACK. It's point of discussion for languages which want "clearity".
BASIC never used to be such a language. And it never claimed to be such
a language. My giving up this basic principle of BASIC, we would not
need VB.NET.

I never saw a professional (I don't claim to be one) programmer making a
mistake because of this feature of VB.NET. If I saw code making use of
the feature /and/ working incorrect, I knew that the person who wrote it
was not a professional. I often see beginners using this feature in a
wrong way. Yes, that's a fact and it's sometimes annoying if you have
to explain to a beginner why he /should not/ use this feature unless he
is sure that he understood it.

Whether you actually see something isn't the gauge is it? It isn't much of
a reach to "know" that programmer's do it.

I don't /know/ programmers who use this feature. That's why I don't
/know/ that programmers make a mistake by misusing this feature.
And it doesn't mean they aren't professional.
It's hard to realize, but its a fact. Programmers who don't even know
the language specs and the behavior of language constructs they use, I
wouldn't call to be "professional".
They might be sloppy or perhaps just careless... or it might
Is a careless programmer really a professional programmer? Is a
careless car driver really a professional car driver? I don't think so.
mean they just don't see the problem. You make it sound like programmers
come in two flavors. What if they have programmed incredible software for
years and yet reference the static variable this way?
Then they are not professional VB.NET developers. If I use a tool, I
try to understand what it does.
Are you going to scream "hey you're not a professional" well no need
to answer that I'm certain I can guess :-)
:-)

It's a dangerous tool, nobody doubts that. But it's a useful tool.

It isn't particularly dangerous and it isn't particularly useful at all (or
perhaps you are describing something else.) Did you read the thread? It
used the word "confusing."

I read the thread, and I don't have a problem with a certain amount of
what you call "confusion" (see above why not).

.NET has its safety features added too. Visual Basic .NET has its
"safety" features too. And it has a box filled with advanced tools
which should not be used by beginners -- they are for use by "Gods"
only.

Well I'll bite... which advanced tools should not be used by beginners? And
where do you administer the tests so they know when they use them? Again
(and always again Herfried (search any thread we have ever had)) you aren't
answering questions, you are defending an undefendable position you have
taken.

I know I am doing the latter. From your point of view it may look
undefendable. I don't doubt that. Nevertheless, I "fight" for the
BASIC in the VB.NET programming language, you seem to fight for
principles in the language which are available in other programming
languages.
Advanced tools (whatever your definition of that might be) aren't
"advanced" because they are especially dangerous. Gosh you yourself used a
car as an example... do you not consider that an advanced tool? Aren't cars
used by beginners? Aren't cars used by old folks, the nearly blind, the
habitually drunk, the teenager on a cell-phone? You want to prevent
somebody from using a datagrid or is the FTP component you think they need
special training on?

I remember that there was a driving license (at least in Austria, where
I live).

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

[Cor]

Hi Herfried,

It was ment for Tom, but you are right, this is a ten times corrected
message and than you see those terrible changing mistakes afterwards.

In my opinion you did change my words Tom very much.

Or are you talking about the metaphors that were in the continuing

messages that you did with Herfried?

(Just to give Tom a nice friendly escape, words are not always as strict as
C#)

:-))

However I was looking for you yesterday, thought that we had the same idea
about this.
But there were not much I had to fight against and sometimes I love it like
yesterday.

:-)

Cor

[Herfried K. Wagner [MVP]]

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

(Just to give Tom a nice friendly escape, words are not always as strict as
C#)

:-))
;-)))
However I was looking for you yesterday, thought that we had the same idea
about this.
But there were not much I had to fight against and sometimes I love it like
yesterday.

Sorry, it was a really annoying day yesterday. Some of my messages were
not posted and I don't have a copy of them any more.

:-(

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

[Tom Leylan]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote...

/You/ said that... I still don't get the point. Why not eliminate
recursion? It can cause stack overflows when used by people who don't
know how to properly use it.
It would seem obvious... because recursion can't be gotten rid of. What
mechanism would you put in place to prevent it? That said your argument
isn't applicable or are you against array bounds checking? Or to use your
wording "why not eliminate garbage collection?"
Who says that this "general rule" must apply to every programming
language? Is a programming language worse than an other if it breaks
the rule but consequently allows the programmer to be faster (or
whatever)? As a result, the programming language may not be perfect for
people who don't know how to use a tool carefully. Those who know how
to do that, will be more productive.
What are you talking about? Theoretical language "T" ? Who says driving
drunk is "bad" what if being drunk you actually drove more carefully than
when you were sober? People generally play the odds... if you know of a
language which breaks accepted rules but is more productive simply name
it... and if you have a moment how you measured the productivity gains.
ACK. It's point of discussion for languages which want "clearity".
BASIC never used to be such a language. And it never claimed to be such
a language. My giving up this basic principle of BASIC, we would not
need VB.NET.
Just cite your source for the development goal of BASIC. The rest of us
know that Kemeny & Kurtz developed it as an "easy-to-learn" educational
language for students.
I don't /know/ programmers who use this feature. That's why I don't
/know/ that programmers make a mistake by misusing this feature.
You can't have met very many people if you haven't seen one make a mistake.
It's hard to realize, but its a fact. Programmers who don't even know
the language specs and the behavior of language constructs they use, I
wouldn't call to be "professional".
It doesn't matter what _you_ call people... that you are wrong that is the
important lesson here.
Is a careless programmer really a professional programmer? Is a
careless car driver really a professional car driver? I don't think so.
Yes... or do the professional drivers you know never have accidents? Have
you seen a car race?
Then they are not professional VB.NET developers. If I use a tool, I
try to understand what it does.
Until when? At what point can they call themselves a professional... or to
the dumb questioning tactic you used earlier "Who says this 'general
rule'must apply to all programmers? What if that programmer doesn't know
VB.NET very well but writes some very good programs and earns $1 million in
a year? What if he writes code very quickly but has static members
referenced through object variables?"
I know I am doing the latter. From your point of view it may look
undefendable. I don't doubt that. Nevertheless, I "fight" for the
BASIC in the VB.NET programming language, you seem to fight for
principles in the language which are available in other programming
languages.
Sort of the zealot excuse?
I remember that there was a driving license (at least in Austria, where
I live).

I believe anybody who checks this thread will see that I was the one who
mentioned driver's licenses and insurance along with car safety features.
You seem to have run out of ways to categorize software developers and are
simply grasping at straws.

I sincerely wish you well.

[Daniel Billingsley]

That sounds right to me, since Cor refuses to engage in a discussion about
any specific points. I got lost somewhere 20 posts ago in his babble about
natural language, and I still haven't seen any rebuttal of Jon's clear and
concise logical argument.

Hey, let me try my own...

Jon, I could see someone saying that certainly an instance of a class IS
that class. I mean an instance of a GUID is a GUID, isn't it? So why not
say that those static class methods are available to the instance, similar
to the way general inheritance works. Maybe something along those lines was
the thinking of the VB team that allowed this.

As you point out, however, there are certainly cases (like the one you've
been using) where an instance is NOT quite the same thing as the class
itself.

I'm with you I think in that looking at both arguments I'd definitely choose
the more restrictive one, even at the expense of making some developers type
a few more characters. Another solution may have been to have something
like both a Thread and a CurrentThread type, so rather than have
Thread.currentThread be a Thread it would be a CurrentThread. The
complexity that would add is mind-boggling, no?

"scorpion53061" <Its the end of the world as we know [e-mail]> wrote in
message news:%2****************@TK2MSFTNGP11.phx.gbl...

Hi All,

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

[Herfried K. Wagner [MVP]]

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

/You/ said that... I still don't get the point. Why not eliminate
recursion? It can cause stack overflows when used by people who don't
know how to properly use it.
It would seem obvious... because recursion can't be gotten rid of.

Why not use an iterative implementation instead which manages the stack
itself?

SCNR
mechanism would you put in place to prevent it? That said your argument
isn't applicable or are you against array bounds checking? Or to use your
wording "why not eliminate garbage collection?"

Garbage collection and array bound checking are different things. Array
bound checking makes sense. Garbage collection makes sense. Recursion
makes sense. And: Accessing shared members through instance variables
makes sense.

Who says that this "general rule" must apply to every programming
language? Is a programming language worse than an other if it breaks
the rule but consequently allows the programmer to be faster (or
whatever)? As a result, the programming language may not be perfect for
people who don't know how to use a tool carefully. Those who know how
to do that, will be more productive.

What are you talking about? Theoretical language "T" ? Who says driving
drunk is "bad" what if being drunk you actually drove more carefully than
when you were sober? People generally play the odds... if you know of a
language which breaks accepted rules but is more productive simply name
it... and if you have a moment how you measured the productivity gains.

Mhm... For example, Visual Basic .NET. It breaks some rules which were
made by the developers of other programming languages which do not apply
to /every/ programming language.

ACK. It's point of discussion for languages which want "clearity".
BASIC never used to be such a language. And it never claimed to be such
a language. My giving up this basic principle of BASIC, we would not
need VB.NET.

Just cite your source for the development goal of BASIC. The rest of us
know that Kemeny & Kurtz developed it as an "easy-to-learn" educational
language for students.

Kemeny and Kurtz didn't make clearness of syntax to one of the basic
principles of their programming language. That was not important to
them (not 1st priority). Their language was easy to learn, included
powerful but dangerous constructs. If you have a look at the BASIC
standards, you will see that these principles still applied to newer
versions of BASIC. And BASIC was successful. Why remove the basic
princliples from the programming language? There are lots of other
programming languages available which put priority to clearity.

I don't /know/ programmers who use this feature. That's why I don't
/know/ that programmers make a mistake by misusing this feature.

You can't have met very many people if you haven't seen one make a mistake.

I have seen programmers making mistakes. I have seen professional
programmers making mistakes because of the comlexity and size of source
code or a project. But I haven't seen professional programmers making
mistakes because of simple things which can be learned simply by reading
the documentation.

It's hard to realize, but its a fact. Programmers who don't even know
the language specs and the behavior of language constructs they use, I
wouldn't call to be "professional".

It doesn't matter what _you_ call people... that you are wrong that is the
important lesson here.

It's important what you call "professional". IMO somebody is a
professional VB.NET programmer, if he doesn't misuse VB.NETs language
features.

If in your definition somebody who doesn't know how to properly use his
tool is a professional, every further discussion doesn't make sense.

Is a careless programmer really a professional programmer? Is a
careless car driver really a professional car driver? I don't think so.

Yes... or do the professional drivers you know never have accidents? Have
you seen a car race?

Programming is not a fight.

Then they are not professional VB.NET developers. If I use a tool, I
try to understand what it does.

Until when? At what point can they call themselves a professional... or to
the dumb questioning tactic you used earlier "Who says this 'general
rule'must apply to all programmers? What if that programmer doesn't know
VB.NET very well but writes some very good programs and earns $1 million in
a year? What if he writes code very quickly but has static members
referenced through object variables?"

Somebody who earns $1 Million by writing a piece of /buggy/ code is IMO
not a professional for the programming language he is using. He may be
professional in economics or something like that. If someone writes
code very quickly referencing static members through instance variables,
he can still be a professional if the code works and if he knows what he
is doing.

I know I am doing the latter. From your point of view it may look
undefendable. I don't doubt that. Nevertheless, I "fight" for the
BASIC in the VB.NET programming language, you seem to fight for
principles in the language which are available in other programming
languages.

Sort of the zealot excuse?

Sorry, what does "zealot" mean?

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

[Jon Skeet [C# MVP]]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

That sounds right to me, since Cor refuses to engage in a discussion about
any specific points. I got lost somewhere 20 posts ago in his babble about
natural language, and I still haven't seen any rebuttal of Jon's clear and
concise logical argument.

Hey, let me try my own...

Jon, I could see someone saying that certainly an instance of a class IS
that class. I mean an instance of a GUID is a GUID, isn't it? So why not
say that those static class methods are available to the instance, similar
to the way general inheritance works. Maybe something along those lines was
the thinking of the VB team that allowed this.
An instance of a GUID is a GUID, certainly, but I'm not sure why that
matters. For instance, using GUID.Empty or GUID.NewGuid() on a specific
instance implies that it has something to do with that instance - that
the new or empty GUID is based on the old one or whatever.
As you point out, however, there are certainly cases (like the one you've
been using) where an instance is NOT quite the same thing as the class
itself.

I'm with you I think in that looking at both arguments I'd definitely choose
the more restrictive one, even at the expense of making some developers type
a few more characters. Another solution may have been to have something
like both a Thread and a CurrentThread type, so rather than have
Thread.currentThread be a Thread it would be a CurrentThread. The
complexity that would add is mind-boggling, no?

Have a CurrentThread type with static members? Mmm... I can see how
that could be useful in terms of clarify. CurrentThread.Wait etc is
clearer than Thread.Wait. I'm not sure that's exactly what you were
suggesting though - I'm not sure you should be able to have *instances*
of the CurrentThread class, because you could stash references to them
which would effectively be inaccurate.

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

[Cor]

Daniel,

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

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

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

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

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

Cor

[One Handed Man [ OHM# ]]

Longest . . . . . Thread . . . . . Ever . . . . !

(___)(___) <---- Too much time on the computer does this !

LOL

Regards - OHM
Herfried K. Wagner [MVP] wrote:

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

/You/ said that... I still don't get the point. Why not eliminate
recursion? It can cause stack overflows when used by people who
don't know how to properly use it.

It would seem obvious... because recursion can't be gotten rid of.

Why not use an iterative implementation instead which manages the
stack itself?

SCNR

mechanism would you put in place to prevent it? That said your
argument isn't applicable or are you against array bounds checking?
Or to use your wording "why not eliminate garbage collection?"

Garbage collection and array bound checking are different things.
Array bound checking makes sense. Garbage collection makes sense.
Recursion makes sense. And: Accessing shared members through
instance variables makes sense.

Who says that this "general rule" must apply to every programming
language? Is a programming language worse than an other if it
breaks the rule but consequently allows the programmer to be faster
(or whatever)? As a result, the programming language may not be
perfect for people who don't know how to use a tool carefully.
Those who know how to do that, will be more productive.

What are you talking about? Theoretical language "T" ? Who says
driving drunk is "bad" what if being drunk you actually drove more
carefully than when you were sober? People generally play the
odds... if you know of a language which breaks accepted rules but is
more productive simply name it... and if you have a moment how you
measured the productivity gains.

Mhm... For example, Visual Basic .NET. It breaks some rules which
were made by the developers of other programming languages which do
not apply to /every/ programming language.

ACK. It's point of discussion for languages which want "clearity".
BASIC never used to be such a language. And it never claimed to be
such a language. My giving up this basic principle of BASIC, we
would not need VB.NET.

Just cite your source for the development goal of BASIC. The rest
of us know that Kemeny & Kurtz developed it as an "easy-to-learn"
educational language for students.

Kemeny and Kurtz didn't make clearness of syntax to one of the basic
principles of their programming language. That was not important to
them (not 1st priority). Their language was easy to learn, included
powerful but dangerous constructs. If you have a look at the BASIC
standards, you will see that these principles still applied to newer
versions of BASIC. And BASIC was successful. Why remove the basic
princliples from the programming language? There are lots of other
programming languages available which put priority to clearity.

I don't /know/ programmers who use this feature. That's why I don't
/know/ that programmers make a mistake by misusing this feature.

You can't have met very many people if you haven't seen one make a
mistake.

I have seen programmers making mistakes. I have seen professional
programmers making mistakes because of the comlexity and size of
source code or a project. But I haven't seen professional
programmers making mistakes because of simple things which can be
learned simply by reading the documentation.

It's hard to realize, but its a fact. Programmers who don't even
know the language specs and the behavior of language constructs
they use, I wouldn't call to be "professional".

It doesn't matter what _you_ call people... that you are wrong that
is the important lesson here.

It's important what you call "professional". IMO somebody is a
professional VB.NET programmer, if he doesn't misuse VB.NETs language
features.

If in your definition somebody who doesn't know how to properly use
his tool is a professional, every further discussion doesn't make
sense.

Is a careless programmer really a professional programmer? Is a
careless car driver really a professional car driver? I don't
think so.

Yes... or do the professional drivers you know never have accidents?
Have you seen a car race?

Programming is not a fight.

Then they are not professional VB.NET developers. If I use a tool,
I try to understand what it does.

Until when? At what point can they call themselves a
professional... or to the dumb questioning tactic you used earlier
"Who says this 'general rule'must apply to all programmers? What if
that programmer doesn't know VB.NET very well but writes some very
good programs and earns $1 million in a year? What if he writes
code very quickly but has static members referenced through object
variables?"

Somebody who earns $1 Million by writing a piece of /buggy/ code is
IMO not a professional for the programming language he is using. He
may be professional in economics or something like that. If someone
writes code very quickly referencing static members through instance
variables, he can still be a professional if the code works and if he
knows what he is doing.

I know I am doing the latter. From your point of view it may look
undefendable. I don't doubt that. Nevertheless, I "fight" for the
BASIC in the VB.NET programming language, you seem to fight for
principles in the language which are available in other programming
languages.

Sort of the zealot excuse?

Sorry, what does "zealot" mean?

--
Best Regards - OHM

O_H_M{at}BTInternet{dot}com

[Tom Leylan]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote...

Why not use an iterative implementation instead which manages the stack
itself?
You wrote "why not eliminate recursion" and I wrote, because you can't. A
developer can implement an alternative solution but that doesn't "get rid of
recursion." What is your hope now that the "static members" thread was
about recursion?
Mhm... For example, Visual Basic .NET. It breaks some rules which were
made by the developers of other programming languages which do not apply
to /every/ programming language.
You are using the exception to the rule as the only example of "languages
that break the rule." The "well officer lots of people drive drunk and
don't run people over"... name somebody... "Mhm... me!" example. Every
language breaks some "rules" once again they are called trade-offs.
Kemeny and Kurtz didn't make clearness of syntax to one of the basic
principles of their programming language.
Just let us know where you found out that Kemeny and Kurtz "didn't make
clearness of syntax to one of the basic principals." You are making this
stuff up.
I have seen programmers making mistakes. I have seen professional
programmers making mistakes because of the comlexity and size of source
code or a project. But I haven't seen professional programmers making
mistakes because of simple things which can be learned simply by reading
the documentation.
Then you can't have met very many professional programmers.
It's important what you call "professional". IMO somebody is a
professional VB.NET programmer, if he doesn't misuse VB.NETs language
features.
That might be your opinion but that doesn't alter the facts. "Misuse" isn't
a black and white issue. It should be obvious from all the messages posted
on this newsgroup and from this thread alone.
If in your definition somebody who doesn't know how to properly use his
tool is a professional, every further discussion doesn't make sense.
There was no discussion taking place. As always you define everything in
terms of yourself and nobody measures up to you. It doesn't matter if they
wrote compilers, or database servers, wrote books or earned a fortune as
long as they "misuse" something (using your definition) they are not
professional.

Is a careless programmer really a professional programmer? Is a
careless car driver really a professional car driver? I don't think

so.
Yes... or do the professional drivers you know never have accidents? Have you seen a car race?

Programming is not a fight.

A fight is not a camera.
Somebody who earns $1 Million by writing a piece of /buggy/ code is IMO
not a professional for the programming language he is using. He may be
professional in economics or something like that.
So that rules out all the developers at Microsoft, IBM, Borland and Sun
right?
Sorry, what does "zealot" mean?

It's a synonym for Herfried K. Wagner [MVP]

[Tom Leylan]

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

Jon, I could see someone saying that certainly an instance of a class IS
that class. I mean an instance of a GUID is a GUID, isn't it? So why not
say that those static class methods are available to the instance, similar
to the way general inheritance works. Maybe something along those lines was the thinking of the VB team that allowed this.

Hi Daniel,

Interesting idea but generally speaking it's hard to consider an instance of
a class as the class. Given a class is a template for creating objects the
object simply cannot be the class since the object is not a template for
creating an object. The object has no "new" constructor so it's missing
some parts of the class.

The blueprints for a building is not a building and a building is not a
blueprint.

Anything can be argued (we see that every day) and most things can be worked
around (we do it every day) but clearly Jon was simply outlining a simple
solution to what can be a confusing situation. That can hardly be
considered a bad thing.

Tom

[One Handed Man [ OHM# ]]

ROTFL

I have to admit, I found the end of your post very funny !

OHM

Sorry, what does "zealot" mean?

It's a synonym for Herfried K. Wagner [MVP]

[Tom Leylan]

Not a problem...
You gave a bunch of well-reasoned responses in the main thread and people
ignored you just like they ignored Jon.

It's just a discussion for gosh sake.
"One Handed Man [ OHM# ]" <O_H_M{at}BTInternet{dot}com> wrote in message
news:Od**************@TK2MSFTNGP11.phx.gbl...

ROTFL

I have to admit, I found the end of your post very funny !

OHM

Sorry, what does "zealot" mean?

It's a synonym for Herfried K. Wagner [MVP]

[Daniel Billingsley]

I hope you didn't get the idea I was disagreeing with Jon. I meant only to
play devil's advocate for a minute and offer one possible way of looking at
it differently. And by that way of looking at your statement isn't correct.
A building is a manifestation of the blueprint, and as such it's length
property could really be "inherited" from the static length property on the
blueprint.

But I just thought of something that would seem very weird to me. what if
you implement a class factory model whereby a static method of the class
returns an instance. That would seem VERY ugly if the instance could also
be a factory, which it could in VB, right? Ugh!

So, again I say even if we could understand one way of looking at things
which might explain keeping that functionality, I agree there are too many
cases where things get muddy right quick.

"Tom Leylan" <ge*@iamtiredofspam.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

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

The blueprints for a building is not a building and a building is not a
blueprint.

Anything can be argued (we see that every day) and most things can be worked around (we do it every day) but clearly Jon was simply outlining a simple
solution to what can be a confusing situation. That can hardly be
considered a bad thing.

Tom

[Daniel Billingsley]

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

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

Daniel,

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

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

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

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

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

Cor

[Tom Leylan]

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

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

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

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

Tom

[Cor]

Hi Daniel,

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

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

Cor

[Sami Vaaraniemi]

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

Rest is inline.

"Tom Leylan" <ge*@iamtiredofspam.com> wrote in message
news:un**************@TK2MSFTNGP11.phx.gbl...

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

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

to

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

at

it differently.

Oh not at all, I saw your point.

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

the

blueprint.

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

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

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