Newbie Question - Using Static (from VB.net) in C#

[damiensawyer]

Hi,

I have some old VB.NET code that I'm converting to C#. Some of it uses
the STATIC keyword. Can someone please tell me how to do this in c#?

Please note, this does NOT do what static in c# syntax does.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vakeystatic.asp

In VB, static is a way to let a variable defined locally to a method,
keep it's value between calls to that method. I 'could' use a private
property inside the class, however, the advantage of vb's static is
that the variable is scoped only to the method in which it resides.

Thanks very much for your help



Damien Sawyer

 

[Guest]

Personally, I think we ex VB proggies just need to get over this classic VB
"thing" (e.g. "why can't I do this in ...)

Certainly a class -level field to hold this value between method calls, if
properly named, should pose no big problems.

Peter

 

[damiensawyer]

*grin*

Peter - I see your point and appreciate the subtleties of your
candor...

I was originally thinking ..."well, if the CLR supports it for VB, why
not C#?"

Now that I think of it again after a relaxing lunch, I suppose that
there would be no 'support' for it in the CLR, just the VB compiler
generating a private field (or something similar).

I miss vb. I want to code in vb.net - however all the 'trendy'
programmers use c# and so I feel a peer pressure to do so.

I actually feel really sorry for the VB.Net team, who, in many
respects delivered a (dare I say) better product than c#, however lose
users because people like me just follow the trend.

There - I've had my rant and will now get off the soapbox and go back
to those annoying damned curley braces....



DS

 

[Guest]

It's not just a VB quirk - C++ has this also.

I think it's left out of C# due to the desire to keep that language as clean
as possible - i.e., there's an existing way to handle it, so local static is
not required (Java and J# are even more barebones than C#).
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant C++: C# to C++ Converter
Instant J#: VB.NET to J# Converter

 

[Guest]

Well put, and exactly why i prefer C# as it is leaner, terser, and all the
"classic" crutches never needed to be put into it since it was designed from
the git-go with the .NET platform in mind, rather than having ancient history
come with it along for the ride to .NET.

BTW, like your product.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

 

[Guest]

Thanks.

Although C# was originally designed to be lean, we'll see if it stays that
way. There is a lot of temptation to start adding wish-list items (we're
already seeing that with anonymous methods - there's other ways to do it
rather than inlining entire methods within statements - shudder). And the
typeless variables that they're talking about for the next release sends
shivers up my spine (variants didn't exactly improve most of the code I saw
in VB6).

--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant C++: C# to C++ Converter
Instant J#: VB.NET to J# Converter

 

[Jon Skeet [C# MVP]]

Thanks.

Although C# was originally designed to be lean, we'll see if it stays that
way. There is a lot of temptation to start adding wish-list items (we're
already seeing that with anonymous methods - there's other ways to do it
rather than inlining entire methods within statements - shudder). And the
typeless variables that they're talking about for the next release sends
shivers up my spine (variants didn't exactly improve most of the code I saw
in VB6).

I'm concerned about the speed of C#'s growth too. Having said that,
LINQ itself appeals massively, and without anonymous types, it would be
a lot harder to work with it.

(Anonymous methods don't bother me too much - at least the syntax is a
lot terser than Java's anonymous inner classes. Having said which, the
business with variable capture is much more complicated than Java's
version...)

I wrote about this when I first got round to looking at the C# 3.0
draft spec properly:

http://msmvps.com/jon.skeet/archive/2005/09/28/68110.aspx

 

[Brian Gideon]

All,

I suppose the debate boils down to benefit vs. complexity which is
mostly subjective. I think in this case the benefit outways the
complexity. Keep in mind though that I am a proponent of a lean
syntax. And, it's not that I really think local static variables are
all that beneficial. I just don't think it adds much complexity to the
language. There would be no new keywords or concepts involved. It's
simply a matter of scope is it not? The benefit, of course, would be
the ability to narrow down the scope of variables. Am I missing
something obvious?

Brian

I do admit

 

[Jon Skeet [C# MVP]]

I suppose the debate boils down to benefit vs. complexity which is
mostly subjective.

No, I don't think so. To my mind, it boils down to benefit vs
philosophical purity.

In my model of object orientation at least, a method doesn't logically
have state. If you've got state in a method which doesn't logically
belong in the state of the object itself, that method should probably
be in a separate class too.

 

[Brian Gideon]

That makes sense. Perhaps that's what the C# compiler team was
thinking as well.

 

[Michael S]

And the
typeless variables that they're talking about for the next release sends
shivers up my spine (variants didn't exactly improve most of the code I
saw
in VB6).

They are not typeless at all. Just inferred. Don't confuse the new var
keyword with variants...

Happy Coding
- Michael S

 

[damiensawyer]

Fair enough... that makes sense to me as well.

I have to say, I had a bit of a chuckle about the "benefit vs
philosophical purity" comment. How far do you go with that though? Is
there a point where the attitude becomes counter productive?

 

[Bruce Wood]

No, I don't think so. To my mind, it boils down to benefit vs
philosophical purity.

I don't see it so much as a philosophical purity problem. More as a
maintenance problem. When I look at the top of a class, I expect to see
_all_ of its state described there, not "most" of its state.

A class that declared a dozen private fields as its "state", but then
had a couple more squirreled away inside methods, would cause me
(initial) confusion: how come this object reacts differently from one
method call to the next in some unexpected way? Ohhh... there are
little bits of object state tucked away inside methods!

Even worse if the "persisted" state within the methods is truly static:
if it ranges across all instances of a class. Then calls to one object
affect calls to other objects of the same class, but a quick look at
the top of the class tells you nothing; you have to think to look at
the method in question to find the answer.

True, the proper use for such persisted method variables would be for
caching and other such techniques that don't affect the public
behaviour of the object, but then it's just as easy to drop stuff like
that into the general object state and get it out in the open.

 

[Michael S]

Fair enough... that makes sense to me as well.

I have to say, I had a bit of a chuckle about the "benefit vs
philosophical purity" comment. How far do you go with that though? Is
there a point where the attitude becomes counter productive?

Hehe. Ask Jon about properties vs. public fields. =)

- Michael S