Naming structs with a variable

[Jon Skeet [C# MVP]]

ah but the discussion has been very spirited.

That's certainly true.

I think we can agree that
1. The existing literature establishes the ground rules.

Well, I don't think I'd call them "ground rules". I'd agree that the
existing literature uses the word "lightweight" in discussions of
structs with varying degrees of accuracy.

2. It's too late to change the established ground rules even without regard
to the fact that they may or may not be correct.

I don't agree with that. In the Java world, many early books
incorrectly stated that Java passed objects by reference. This caused a
great deal of confusion. Are you saying you think those books shouldn't
have been corrected, and the correct terminology used? As another
example, are you suggesting that MSDN shouldn't have been fixed to
correctly describe System.Decimal as a floating point type instead of a
fixed point type? Are you suggesting that people should go along with
the idea that ASCII has 256 values, just because lots of web pages (and
some MSDN pages) claim that it has?

If something is incorrect, it should be pointed out as being incorrect.
Pretending that something is correct just because it's widely
stated/believed is a really bad idea.

How about the whole universe going round the earth, by the way? That
was one of the "established ground rules" before it was challenged...

3. Concepts defined within the C# language should not be viewed within the
context of other languages.

Well, they can be compared with other languages, but only carefully.

4. Programmers must understand language facets in detail before using these
constructs in production code especially where these constructs may have
have performance consequences or may be used in time-sensitive applications.

I don't think performance is actually the key concern here - that's one
of the things that bothers me about simply describing structs as
"lightweight classes" - it ignores the most important part (value type
semantics) and concentrates on the efficiency part (and overgeneralises
that too).

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I think we can agree that

1. The existing literature establishes the ground rules.

No, not ground rules as such. The existing literature is always the
existing literature, and can not be discarded as such, but parts of the
existing literature will always be more or less inaccurate.

The quality of the existing literature can be viewed using chaos theory.
Any section of the literature that is regarded as generally correct will
always contain parts that are incorrect. If you reduce the size of the
section to isolate a part that is absolutely correct, the section will
be so small that it's practically unusable.

2. It's too late to change the established ground rules even without regard
to the fact that they may or may not be correct.

It's never too late to change the general conception of the rules. The
history is full of examples on this...

3. Concepts defined within the C# language should not be viewed within the
context of other languages.

So true. Still, people will always compare elements of new languages to
similar elements in languages they already know. The syntax of C# is
very similar to C, C++ and Java, so anyone coming from any of those
platforms will naturally use their previous knowledge, and for the most
part that will work fine as many aspects of the languages work exactly
the same. There is no problem until you come to aspects of the language
that works differently from previous similar languages. That's why it's
important that those apsects are explained in a way that doesn't imply
similarities with other languages that aren't true.

4. Programmers must understand language facets in detail before using these
constructs in production code especially where these constructs may have
have performance consequences or may be used in time-sensitive applications.

Yes, that would be the ideal situation. Still, there are a lot of
programmers out there who use things that they barely know enough about
to make them work, much less have detailed knowledge about...