Static Members

[Tom Leylan]

/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?

 

[Herfried K. Wagner [MVP]]

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.

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.

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.

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

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

Programming is not a fight.

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.

Sort of the zealot excuse?

Sorry, what does "zealot" mean?

 

[Jon Skeet [C# MVP]]

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.

 

[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

 

[Tom Leylan]

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.

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]

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

 

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

 

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

 

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

 

[Tom Leylan]

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.

Oh not at all, I saw your point.


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