Another novice question

[gordon]

I aksed a few days ago about static methods and got some good answers that
were really useful.

Now I am not sure if about the use of static on members (variables) and
classes.

Can someone please give me some advice about static classes and members too?

Thanks

Doug

[Cor Ligthert [MVP]]

Gordon,

Just as rule for yourself, if you *can* avoid them, than avoid them.

They keep forever the memory occupied and therefore you should use them in
my opinion there were you are sure that you needs them endless times and
don't need more instances of them.

(Be aware that there is other behaviour for ASPNET applications than for
WindowForms applications about static, just because a windowforms is a
client while an ASPNET application is a middle tier)

However (not the later sentence), just my idea.

Cor

"gordon" <go**********@optusnet.com.auschreef in bericht
news:44**********************@news.optusnet.com.au ...

>I aksed a few days ago about static methods and got some good answers that
were really useful.

Now I am not sure if about the use of static on members (variables) and
classes.

Can someone please give me some advice about static classes and members
too?

Thanks

Doug

[Marc Gravell]

I'm not sure I'd put it quite as strongly as Cor... static members do
have their place... but if you have static fields [fields=class level
variables] on a class, then the biggest thing you need to consider is
thread safety - not a trivial subject.

Simple static "helper" functions that don't talk to static fields are
intrinsicly thread-safe, but as soon as fields are involved you need to
be aware that in a non-trivial app different threads may be using the
static class at once, so the impact needs to be understood...

Of course, if you *know* you aren't going to be using threading, then
OK ;-p

Jon Skeet has a very good article on threading - note it goes into many
pages...
http://www.yoda.arachsys.com/csharp/threads/

Marc

[Nicholas Paldino [.NET/C# MVP]]

This doesn't make any sense. A static method doesn't keep any memory
occupied beyond the stack that is allocated when the call is made.

However, when the method exits, the memory for the stack is gone as
well.

Static fields are a different story, and yes, they will last as long as
the application domain lasts. However, saying that you shouldn't use them
is a premature optimization, since in reality, they might be pointing to an
object, and the size of the reference is not high. Even if the object is
big, instance members can reference large objects, and live for the life of
an app domain as well, depending on the use.

Also, ASP.NET does not treat static fields any differently. Static
fields live for the life of the app domain, no more, no less. Granted,
ASP.NET recylces app domains, and one has to be aware of that, but static
fields have no say in that, it is the runtime of ASP.NET that determines
that.

In the end, the OP asked about static methods, not static fields.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:ev**************@TK2MSFTNGP04.phx.gbl...

Gordon,

Just as rule for yourself, if you *can* avoid them, than avoid them.

They keep forever the memory occupied and therefore you should use them in
my opinion there were you are sure that you needs them endless times and
don't need more instances of them.

(Be aware that there is other behaviour for ASPNET applications than for
WindowForms applications about static, just because a windowforms is a
client while an ASPNET application is a middle tier)

However (not the later sentence), just my idea.

Cor

"gordon" <go**********@optusnet.com.auschreef in bericht
news:44**********************@news.optusnet.com.au ...

>>I aksed a few days ago about static methods and got some good answers that
were really useful.

Now I am not sure if about the use of static on members (variables) and
classes.

Can someone please give me some advice about static classes and members
too?

Thanks

Doug

[Cor Ligthert [MVP]]

Did I write what you wrote?

>
Also, ASP.NET does not treat static fields any differently. Static
fields live for the life of the app domain, no more, no less. Granted,
ASP.NET recylces app domains, and one has to be aware of that, but static
fields have no say in that, it is the runtime of ASP.NET that determines
that.

The behaviour of a windowforms program is different than an ASPNET
application, just because in a windowform program the client is the
application and in a aspnet application that it the genereated
HTML/Javascript page. Therefore the complete application behaves different.
A static method in a ASPNET application acts for the rest the same as in any
other C# application.

Static means fixed. In old non by the OS relocatable programs (C) it means
true fixed to a memory address. In more modern OS it means fixed to the
memory starting point where the program is located. In my idea can there
never been an other description for that otherwise the Static keyword is in
my idea wrong used.

However just my thought,

Cor

[Nicholas Paldino [.NET/C# MVP]]

Cor,

Again, you are making a premature optimization. If the design calls for
a static member, then you should use a static member. An extra field
reference isn't going to bring your app tumbling down.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:Ok**************@TK2MSFTNGP05.phx.gbl...

Did I write what you wrote?

>>
Also, ASP.NET does not treat static fields any differently. Static
fields live for the life of the app domain, no more, no less. Granted,
ASP.NET recylces app domains, and one has to be aware of that, but static
fields have no say in that, it is the runtime of ASP.NET that determines
that.

The behaviour of a windowforms program is different than an ASPNET
application, just because in a windowform program the client is the
application and in a aspnet application that it the genereated
HTML/Javascript page. Therefore the complete application behaves
different. A static method in a ASPNET application acts for the rest the
same as in any other C# application.

Static means fixed. In old non by the OS relocatable programs (C) it means
true fixed to a memory address. In more modern OS it means fixed to the
memory starting point where the program is located. In my idea can there
never been an other description for that otherwise the Static keyword is
in my idea wrong used.

However just my thought,

Cor

[Cor Ligthert [MVP]]

Nick,

It is great, but where is the intention from your current message different
from the first line in the one I started with?

Yours

Again, you are making a premature optimization. If the design calls
for a static member, then you should use a static member. An extra field
reference isn't going to bring your app tumbling down.

Mine

>>Just as rule for yourself, if you *can* avoid them, than avoid them.

I did nowhere write that you *should* not use them.

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] <no************@planet.nlwrote:

It is great, but where is the intention from your current message different
from the first line in the one I started with?

Yours

Again, you are making a premature optimization. If the design calls
for a static member, then you should use a static member. An extra field
reference isn't going to bring your app tumbling down.

Mine

>Just as rule for yourself, if you *can* avoid them, than avoid them.

I did nowhere write that you *should* not use them.

But you're suggesting that you should avoid them where possible - in
other words, that it's worth skewing the design in order to avoid them.
I, like Nicholas, disagree with that. If a static member is the natural
design, there's no need to avoid it.

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

[Cor Ligthert [MVP]]

Jon,

Where is a static class or a whatever class a natural design.

I don't know if you believe in the great Englisman Darwin, otherwise have a
look in the Bibble both is about natural design. A static class is never for
me a Natural design as is not any class.

Both you are writing "an extra field reference isn't going to bring your app
tubling down"

I cannot place the context of this message, is this something Nick has
stated in this thread.

You should know that I would be the last one who would write that, therefore
we have had to much discussions about by instance avoiding boxing. From
which I write forever that you should try to avoid that but not put to much
effort in that.

So I am curious in what context you place that sentence?

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...

Cor Ligthert [MVP] <no************@planet.nlwrote:

>It is great, but where is the intention from your current message
different
from the first line in the one I started with?

Yours

Again, you are making a premature optimization. If the design calls
for a static member, then you should use a static member. An extra
field
reference isn't going to bring your app tumbling down.

Mine

>>Just as rule for yourself, if you *can* avoid them, than avoid them.

I did nowhere write that you *should* not use them.

But you're suggesting that you should avoid them where possible - in
other words, that it's worth skewing the design in order to avoid them.
I, like Nicholas, disagree with that. If a static member is the natural
design, there's no need to avoid it.

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

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] <no************@planet.nlwrote:

Where is a static class or a whatever class a natural design.

Where utility methods are required, for starters. Besides, you didn't
originaly limit yourself to static classes, but to all static
variables.

At that point, you're preventing patterns such as the singleton pattern
(which does have disadvantages, but is appropriate sometimes).

I don't know if you believe in the great Englisman Darwin, otherwise have a
look in the Bibble both is about natural design. A static class is never for
me a Natural design as is not any class.

What would you do with HttpUtility then, just as an example? All its
members are static, so it effectively could (and should) be a static
class. The fact that it's got a public constructor is a mistake,
basically.

How about the System.Math class?

Both you are writing "an extra field reference isn't going to bring your app
tubling down"

Actually, I never wrote that.

I cannot place the context of this message, is this something Nick has
stated in this thread.

You should know that I would be the last one who would write that, therefore
we have had to much discussions about by instance avoiding boxing. From
which I write forever that you should try to avoid that but not put to much
effort in that.

Again though - where the design naturally uses boxing, it's fine to use
boxing.

So I am curious in what context you place that sentence?

You said to avoid static members where you *can* avoid them. You almost
always *can* avoid them - which means that by your standards, they
should virtually never be used.

Here's an example. Consider the Encoding class and its ASCII property.
That *could* create a new instance of ASCIIEncoding each time, instead
of caching it in a static variable. So one *can* avoid using a static
variable - and according to your logic, one therefore *should* avoid
it. Now, how is creating an instance of ASCIIEncoding every time
Encoding.ASCII is used actually a *good* idea? Do you like having lots
of instances of classes which effectively have no state?

Now, if you didn't actually mean your statement to be as strong as it
was, you shouldn't have made it that way. I can only go by what you've
actually written...

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

[Cor Ligthert [MVP]]

Jon and Nick,

You both read more in what I wrote than I have ever thought about.
Amazing:let me try to give an anology.

In England I try to avoid looking first to the right and than keep my eyes
on the left when I cross a street as I am there. Because I am forever always
the first days a novice in that country. In that perspective should my
advice be seen.

I have seen that newbies take quick the way of modulair programming what in
my eyes using static is. That it is used by an OOP programming language as
C++, VB.Net, VB# or whatever does not change that.

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...

Cor Ligthert [MVP] <no************@planet.nlwrote:

>Where is a static class or a whatever class a natural design.

Where utility methods are required, for starters. Besides, you didn't
originaly limit yourself to static classes, but to all static
variables.

At that point, you're preventing patterns such as the singleton pattern
(which does have disadvantages, but is appropriate sometimes).

>I don't know if you believe in the great Englisman Darwin, otherwise have
a
look in the Bibble both is about natural design. A static class is never
for
me a Natural design as is not any class.

What would you do with HttpUtility then, just as an example? All its
members are static, so it effectively could (and should) be a static
class. The fact that it's got a public constructor is a mistake,
basically.

How about the System.Math class?

>Both you are writing "an extra field reference isn't going to bring your
app
tubling down"

Actually, I never wrote that.

>I cannot place the context of this message, is this something Nick has
stated in this thread.

You should know that I would be the last one who would write that,
therefore
we have had to much discussions about by instance avoiding boxing. From
which I write forever that you should try to avoid that but not put to
much
effort in that.

Again though - where the design naturally uses boxing, it's fine to use
boxing.

>So I am curious in what context you place that sentence?

You said to avoid static members where you *can* avoid them. You almost
always *can* avoid them - which means that by your standards, they
should virtually never be used.

Here's an example. Consider the Encoding class and its ASCII property.
That *could* create a new instance of ASCIIEncoding each time, instead
of caching it in a static variable. So one *can* avoid using a static
variable - and according to your logic, one therefore *should* avoid
it. Now, how is creating an instance of ASCIIEncoding every time
Encoding.ASCII is used actually a *good* idea? Do you like having lots
of instances of classes which effectively have no state?

Now, if you didn't actually mean your statement to be as strong as it
was, you shouldn't have made it that way. I can only go by what you've
actually written...

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

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] <no************@planet.nlwrote:

You both read more in what I wrote than I have ever thought about.

Then you should have written more carefully. We only expected you to
mean what you said. I don't think that's unreasonable.

Amazing:let me try to give an anology.

In England I try to avoid looking first to the right and than keep my eyes
on the left when I cross a street as I am there. Because I am forever always
the first days a novice in that country. In that perspective should my
advice be seen.

And unless the road has "look right" on, that's entirely reasonable.
The difference is that that is good advice - whereas "avoid static
members whenever you can" is bad advice.

I have seen that newbies take quick the way of modulair programming what in
my eyes using static is. That it is used by an OOP programming language as
C++, VB.Net, VB# or whatever does not change that.

And I would never suggest using static methods exclusively. Don't throw
the baby out with the bathwater though - just because statics shouldn't
be *overused* doesn't mean they shouldn't be used at all.

Similarly, just because static classes shouldn't be overused doesn't
mean they're never part of a good design, as you claimed.

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

[Chris Mullins]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote

Cor Ligthert [MVP] <no************@planet.nlwrote:

>I have seen that newbies take quick the way of modulair programming
what in my eyes using static is. That it is used by an OOP programming
language as C++, VB.Net, VB# or whatever does not change that.

And I would never suggest using static methods exclusively. Don't throw
the baby out with the bathwater though - just because statics shouldn't
be *overused* doesn't mean they shouldn't be used at all.

Similarly, just because static classes shouldn't be overused doesn't
mean they're never part of a good design, as you claimed.

Quite the opposite: I am a huge fan on static classes. Until a way is
devised to indicate a particular method or set of methods is stateless, this
is the best way to do things. As we teach all the server developers:

- State Causes Affinity
- Affinity is the Enemy of Performance
Therefore: Avoid State.

One of these days I'm going to write the StatelessMethodAttribute, and build
an FxCop rule to check for member / property access withing the method.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins

[Ben newsam]

On Fri, 8 Sep 2006 06:01:58 +0200, "Cor Ligthert [MVP]"
<no************@planet.nlwrote:

>In England I try to avoid looking first to the right and than keep my eyes
on the left when I cross a street as I am there.

Bad idea. Although we drive on the left, which you may find confusing,
it is a Good Plan to look *both* ways, lol.

--
Posted via a free Usenet account from http://www.teranews.com

[Ben newsam]

On Thu, 7 Sep 2006 18:57:09 +0200, "Cor Ligthert [MVP]"
<no************@planet.nlwrote:

>Where is a static class or a whatever class a natural design.

Well... I wrote a class to access the Registry, inserting a default
value if the key in question was not found. To me, that would always
be a static class, as there is never a need to instantiate it. It just
does stuff, and any data it contains is always the same.

--
Posted via a free Usenet account from http://www.teranews.com

[Cor Ligthert [MVP]]

This message does not need any answer, to rude and to much beside any
reasonable truth.

Just for those who read it in future.

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] <no************@planet.nlwrote:

This message does not need any answer, to rude and to much beside any
reasonable truth.

Just for those who read it in future.

It's too rude to expect you to mean what you say? I don't see how. I
think I've given pretty straightforward reasons why I disagree with
you.

If you truly believe that static classes and static variables are never
part of a good design, stick up for that belief and debate it. If you
don't truly believe it, then retract your previous statement.

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

[Jon Skeet [C# MVP]]

Chris Mullins <cm******@yahoo.comwrote:

Similarly, just because static classes shouldn't be overused doesn't
mean they're never part of a good design, as you claimed.

Quite the opposite: I am a huge fan on static classes. Until a way is
devised to indicate a particular method or set of methods is stateless, this
is the best way to do things. As we teach all the server developers:

- State Causes Affinity
- Affinity is the Enemy of Performance
Therefore: Avoid State.

One of these days I'm going to write the StatelessMethodAttribute, and build
an FxCop rule to check for member / property access withing the method.

Well, there's an alternative I'm becoming quite a fan of - inversion of
control with something like the Spring framework, creating instances
which *after creation* don't change state.

That way you can still configure components (which makes life really
handy for unit testing) and have multiple instances doing different
jobs (eg validating text using different regular expressions) but still
keep the performance of stateless classes by ensuring that the state
won't change. So long as all the threads using the components aren't
created until after the components have been created, there should be
no thread safety issues (or at least, no more than with static
classes). Is this a pattern you've tried and found wanting?

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

[Chris Mullins]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote
[Stateless Programming]

>One of these days I'm going to write the StatelessMethodAttribute, and
build
an FxCop rule to check for member / property access withing the method.

Well, there's an alternative I'm becoming quite a fan of - inversion of
control with something like the Spring framework, creating instances
which *after creation* don't change state.

That way you can still configure components (which makes life really
handy for unit testing) and have multiple instances doing different
jobs (eg validating text using different regular expressions) but still
keep the performance of stateless classes by ensuring that the state
won't change. So long as all the threads using the components aren't
created until after the components have been created, there should be
no thread safety issues (or at least, no more than with static
classes). Is this a pattern you've tried and found wanting?

I have gone quite a bit down the immutable class route in more recent
months. More and more of my objects are constructed, then never changed.
When a change happens, the entire object is replaced with a new one. The
ReadOnly keyword in C# has helped with this. This has been a big help in
terms on elimination of contention in the general case.

I'll have to take a look at that pattern and framework. Thanks for the
pointer.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins

[Cor Ligthert [MVP]]

Jon Skeet.

If you truly believe that static classes and static variables are never
part of a good design, stick up for that belief and debate it. If you
don't truly believe it, then retract your previous statement.

This is not even misquouting, this is putting on this board (Internet)
something I never wrote giving people the idea that I did.

Maybe it is in your opinion not rude, I will not place on Interenet what my
opinion is about this kind of behaviour.

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] <no************@planet.nlwrote:

Jon Skeet.

If you truly believe that static classes and static variables are never
part of a good design, stick up for that belief and debate it. If you
don't truly believe it, then retract your previous statement.

This is not even misquouting, this is putting on this board (Internet)
something I never wrote giving people the idea that I did.

Maybe it is in your opinion not rude, I will not place on Interenet what my
opinion is about this kind of behaviour.

Well, you certainly *did* write this:

<quote>
I don't know if you believe in the great Englisman Darwin, otherwise
have a look in the Bibble both is about natural design. A static class
is never for me a Natural design as is not any class.
</quote>

Okay, I changed the word "natural" for "good" but I don't think that's
very much of a stretch. If you didn't mean that you don't believe
static classes are ever a good design, please explain what you really
*did* mean.

Similarly, if by writing (about static methods and variables and
classes:

<quote>
Just as rule for yourself, if you *can* avoid them, than avoid them.
</quote>

you didn't actually mean to be taken literally, then you should explain
more carefully what you really *did* mean.

I'll say it again: you can't blame us if you write things and we take
them at face value.

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

[Cor Ligthert [MVP]]

Some quotes from Jon. Complete they are below in the message.

Okay, I changed the word "natural" for "good" but I don't think that's
very much of a stretch.

you didn't actually mean to be taken literally, then you should explain
more carefully what you really *did* mean.

I'll say it again: you can't blame us if you write things and we take
them at face value

Strange if you are yourself changing the word "natural" as Nick stated in
"good". While I was only explaining that for me the meaning "natural" has
for me not any meaning inside a design, beside those as done by God or
Nature (depends on what you believe, for me it is Nature) but that has
nothing to do with developing programs.

If a design is good has for me, is depending on the circumstances it is made
for, what is in one case wrong can be in another situation good. Avoiding
details as using static or whatever in advance can not even come in my mind
by that. However I will stay saying to a novice who has never used classes
or whatever. "*Try* to avoid static classes". I know myself that I took the
first times quickly static classes (methods properties) while it was better
to do not (modular programming).

As well I don't understand why you are writing "us". Is Nick or somebody
else sitting beside you at the moment?

In my language the word "us" for a single person can only be used for the
Queen and AFAIK is that in Britain as well, I thought that you are living at
Reading not at Buckingham.

Therefore don't blame others for what you do yourself and bring yourself but
also others probably in confusion.

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...

Cor Ligthert [MVP] <no************@planet.nlwrote:

>Jon Skeet.

If you truly believe that static classes and static variables are never
part of a good design, stick up for that belief and debate it. If you
don't truly believe it, then retract your previous statement.

This is not even misquouting, this is putting on this board (Internet)
something I never wrote giving people the idea that I did.

Maybe it is in your opinion not rude, I will not place on Interenet what
my
opinion is about this kind of behaviour.

Well, you certainly *did* write this:

<quote>
I don't know if you believe in the great Englisman Darwin, otherwise
have a look in the Bibble both is about natural design. A static class
is never for me a Natural design as is not any class.
</quote>

Okay, I changed the word "natural" for "good" but I don't think that's
very much of a stretch. If you didn't mean that you don't believe
static classes are ever a good design, please explain what you really
*did* mean.

Similarly, if by writing (about static methods and variables and
classes:

<quote>
Just as rule for yourself, if you *can* avoid them, than avoid them.
</quote>

you didn't actually mean to be taken literally, then you should explain
more carefully what you really *did* mean.

I'll say it again: you can't blame us if you write things and we take
them at face value.

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

[Ben newsam]

On Sat, 9 Sep 2006 06:31:40 +0200, "Cor Ligthert [MVP]"
<no************@planet.nlwrote:

>This is not even misquouting, this is putting on this board (Internet)
something I never wrote giving people the idea that I did.

Indeed. What you actually wrote was:

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
Just as rule for yourself, if you *can* avoid them, than avoid them.

They keep forever the memory occupied and therefore you should use
them in my opinion there were you are sure that you needs them endless
times and don't need more instances of them.
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

so a little confusion in people's minds is perhaps understandable.

--
Posted via a free Usenet account from http://www.teranews.com

[Cor Ligthert [MVP]]

Ben,

What is not right in that?

Cor

"Ben newsam" <be********@ukonline.co.ukschreef in bericht
news:00********************************@4ax.com...

On Sat, 9 Sep 2006 06:31:40 +0200, "Cor Ligthert [MVP]"
<no************@planet.nlwrote:

>>This is not even misquouting, this is putting on this board (Internet)
something I never wrote giving people the idea that I did.

Indeed. What you actually wrote was:

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
Just as rule for yourself, if you *can* avoid them, than avoid them.

They keep forever the memory occupied and therefore you should use
them in my opinion there were you are sure that you needs them endless
times and don't need more instances of them.
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

so a little confusion in people's minds is perhaps understandable.

--
Posted via a free Usenet account from http://www.teranews.com

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] <no************@planet.nlwrote:

Okay, I changed the word "natural" for "good" but I don't think that's
very much of a stretch.

you didn't actually mean to be taken literally, then you should explain
more carefully what you really *did* mean.

I'll say it again: you can't blame us if you write things and we take
them at face value

Strange if you are yourself changing the word "natural" as Nick stated in
"good". While I was only explaining that for me the meaning "natural" has
for me not any meaning inside a design, beside those as done by God or
Nature (depends on what you believe, for me it is Nature) but that has
nothing to do with developing programs.

Ah, I understand now. Sorry, it wasn't very clear before. I suspect
most of the confusion is due to English not being your first language -
which of course is no-one's fault at all.

I think your definition of "natural" is more limited than motst,
however. The meaning I was using is most closely aligned to one of the
ones in my dictionary at home: "as is normal or expected; ordinary or
logical".

As an example, consider a class which needs to represent a number
between 0 and 65535. You *could* represent it as two byte fields. That
would be an unnatural design. The *natural* design would be to use a
single ushort variable. Do you see what I mean now, and how it works
with the meaning quoted above?

If a design is good has for me, is depending on the circumstances it is made
for, what is in one case wrong can be in another situation good. Avoiding
details as using static or whatever in advance can not even come in my mind
by that.

However I will stay saying to a novice who has never used classes
or whatever. "*Try* to avoid static classes".

Except that's not what you said. You said:

<quote>
Just as rule for yourself, if you *can* avoid them, than avoid them.
</quote>

That's different. Even as "try" I would say it's bad advice. Better
advice would be:

"When designing classes, always consider which members should be
instance members (i.e. to do with that particular instance of the
class) and which members should be static members (i.e. to do with the
type as a whole. This is part of learning to design in an object-
oriented fashion."

That doesn't lend a bias towards either side of things, unlike your
advice, which would end up with people making instance members which
should really be static members.

I know myself that I took the first times quickly static classes
(methods properties) while it was better to do not (modular
programming).

And it's entirely reasonable to suggest to people that they should
think carefully about things, but to make people shy away from static
members unnecessarily is a bad idea IMO. I don't like making statement
for the sake of novices which end up causing problems later on.

As well I don't understand why you are writing "us". Is Nick or somebody
else sitting beside you at the moment?

No, but you've already indicated that you agree we both misinterpreted
what you wrote:

<quote>
You both read more in what I wrote than I have ever thought about.
</quote>

I think it's reasonable to write as "us" in a response - I doubt that
Nick would particularly want to distance himself from the last sentence
of my previous post.

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

[Cor Ligthert [MVP]]

Jon,

Maybe nice to know for you. In Dutch we have the word "Natuurlijk". (Very
much related to natural")
It has two meanings. Created by nature and something as "Of course" but not
that strict. Why would I than not use that the same in English? I find it
forever cheap telling that the reason is onothers language that you made a
mistake in a discussion. Than a professional developer verifies first if
what he had read is confirm what is the meaning of the one who wrote it.
This should be in my idea the first lesson for a developer before all things
as code..

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...

Cor Ligthert [MVP] <no************@planet.nlwrote:

Okay, I changed the word "natural" for "good" but I don't think that's
very much of a stretch.

you didn't actually mean to be taken literally, then you should explain
more carefully what you really *did* mean.

I'll say it again: you can't blame us if you write things and we take
them at face value

Strange if you are yourself changing the word "natural" as Nick stated in
"good". While I was only explaining that for me the meaning "natural" has
for me not any meaning inside a design, beside those as done by God or
Nature (depends on what you believe, for me it is Nature) but that has
nothing to do with developing programs.

Ah, I understand now. Sorry, it wasn't very clear before. I suspect
most of the confusion is due to English not being your first language -
which of course is no-one's fault at all.

I think your definition of "natural" is more limited than motst,
however. The meaning I was using is most closely aligned to one of the
ones in my dictionary at home: "as is normal or expected; ordinary or
logical".

As an example, consider a class which needs to represent a number
between 0 and 65535. You *could* represent it as two byte fields. That
would be an unnatural design. The *natural* design would be to use a
single ushort variable. Do you see what I mean now, and how it works
with the meaning quoted above?

>If a design is good has for me, is depending on the circumstances it is
made
for, what is in one case wrong can be in another situation good. Avoiding
details as using static or whatever in advance can not even come in my
mind
by that.

>However I will stay saying to a novice who has never used classes
or whatever. "*Try* to avoid static classes".

Except that's not what you said. You said:

<quote>
Just as rule for yourself, if you *can* avoid them, than avoid them.
</quote>

That's different. Even as "try" I would say it's bad advice. Better
advice would be:

"When designing classes, always consider which members should be
instance members (i.e. to do with that particular instance of the
class) and which members should be static members (i.e. to do with the
type as a whole. This is part of learning to design in an object-
oriented fashion."

That doesn't lend a bias towards either side of things, unlike your
advice, which would end up with people making instance members which
should really be static members.

>I know myself that I took the first times quickly static classes
(methods properties) while it was better to do not (modular
programming).

And it's entirely reasonable to suggest to people that they should
think carefully about things, but to make people shy away from static
members unnecessarily is a bad idea IMO. I don't like making statement
for the sake of novices which end up causing problems later on.

>As well I don't understand why you are writing "us". Is Nick or somebody
else sitting beside you at the moment?

No, but you've already indicated that you agree we both misinterpreted
what you wrote:

<quote>
You both read more in what I wrote than I have ever thought about.
</quote>

I think it's reasonable to write as "us" in a response - I doubt that
Nick would particularly want to distance himself from the last sentence
of my previous post.

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