basic newbie question about types

[Stephanie_Stowe]

I am reading my newbie documentation about .NET framework. I have come
across this sentence on the very first page:

The .NET Framework class library is a collection of reusable types that
tightly integrate with the common language runtime.

What is a type? Does it parallel anything in Java lingo? I am thinking
that package=class library. Is this correct? Does "type" parallel an
object with attributes and methods?

Not exactly an easy thing to search for a definition of since this
particular word is everywhere.

Sorry if this is too stupid of a question. If so, maybe it will become
clear as I continue reading.

Thanks

 

[Jon Skeet [C# MVP]]

I am reading my newbie documentation about .NET framework. I have come
across this sentence on the very first page:

The .NET Framework class library is a collection of reusable types that
tightly integrate with the common language runtime.

What is a type? Does it parallel anything in Java lingo? I am thinking
that package=class library. Is this correct? Does "type" parallel an
object with attributes and methods?

Type is the same in .NET as it is in Java - the difference is that in
Java, the only value types available are the primitive types.

Basically, a type is a struct, class, enum, delegate etc.

 

[Scott M.]

And all types are either Value Types or Reference Types. Most types are
Reference Types (classes), while some types are Value Types (structures).
Value Types are stored in memory on the Stack and Reference Types are stored
in memory on the Heap.

 

[Stephanie_Stowe]

Thank you both!

 

[Jon Skeet [C# MVP]]

And all types are either Value Types or Reference Types. Most types are
Reference Types (classes), while some types are Value Types (structures).
Value Types are stored in memory on the Stack and Reference Types are stored
in memory on the Heap.

No no no. See http://www.pobox.com/~skeet/csharp/memory.html

The idea that value types are always stored on the stack is wrong and
confusing.

 

[Tom]

A Type is an object that describes a data type ie..

class MyClass
{
int x;
void MyMember();
}


Type t=typeof(MyClass);

Now I have an object t that represents MyClass. I can as t things like
what are you Members or what are your Methods. Or ask t what MyClass
is derived from.

Types are the backbone of .NET reflection, which is the primary
difference over C++.

Start by looking up System.Type in MSDN.

Hope it helps

Thomas

 

[Scott M.]

Jon, is your point simply that "a struct variable which is an instance field
of a class will be on the heap".

If so, I think you are splitting hairs here and while you are correct, I
don't think it is confusing to say that Value Types get stored on the Stack
and Reference Types get stored on the Heap.

Your point is valid, but for a newbie question like this, I think it would
be more confusing to throw this in at this point. The basic tutelage that
vt = stack and rt = heap, is a good way to begin thinking about types and
memory.

IMHO

 

[Jon Skeet [C# MVP]]

Jon, is your point simply that "a struct variable which is an instance field
of a class will be on the heap".

Yup. (Same with any static variable, too.)

If so, I think you are splitting hairs here and while you are correct, I
don't think it is confusing to say that Value Types get stored on the Stack
and Reference Types get stored on the Heap.

Let's just say that people have been confused by people saying that in
the past. Even if it's not confusing to most people, the fact that
people have had to get clarification on newsgroups after being confused
by exactly this kind of statement is enough to suggest to me that it's
not a wise thing to say.

Your point is valid, but for a newbie question like this, I think it would
be more confusing to throw this in at this point. The basic tutelage that
vt = stack and rt = heap, is a good way to begin thinking about types and
memory.

I never like that kind of thing. That's like saying that objects are
passed by reference, rather than explaining that the reference is
passed by value. People claim that saying objects are passed by
reference isn't confusing too - again, I've seen people be confused by
it.

Why give a wrong answer when it's fairly easy to explain what actually
happens? (Of course, I'm in a slightly stronger position here, having
written a page which explains it carefully and (given people's
reactions) clearly. Feel free to refer to the page in future.)

 

[Scott M.]

I don't think my answer is wrong. I've seen it explained in just the way
that I explained it in MS Press and WROX books. If you take a "pure"
structure (one that simply stores value types), then the explanation is
valid.

I think that what you have written on your page (while very good
information) is an exception to a rule and not a rule in and of itself.

I've never really heard of anyone being confused by this. Essentially we
are saying that in cases where structures contain reference types, they will
be stored on the heap, rather than the stack. Which, if you think about it,
follows what I said originally (reference types are stored on the heap).

 

[Jon Skeet [C# MVP]]

I don't think my answer is wrong.

It is, very definitely. Here's an example:

class Test
{
int i;

static void Main()
{
Test t = new Test();
t.i=5;
}
}

Now:

1) int is a value type
2) t.i is a value type variable
3) t.i is on the heap

Which of those statements do you disagree with?

Or how about:

class Test
{
static int foo = 10;

static void Main()
{
Console.WriteLine (foo);
}
}

Where do you think foo is stored?

I've seen it explained in just the way that I explained it in MS
Press and WROX books.

That doesn't make it right. There were various Java books which claimed
that objects were passed by reference, until it became widely
understood that this is completely wrong. Fortunately it's a rare
mistake to find in books these days.

Heck, the first edition of "C# in a Nutshell" claims that char and bool
are floating-point types! Books can contain mistakes.

If you take a "pure" structure (one that simply stores value types),
then the explanation is valid.

Only if that structure is never part of a reference type.

I think that what you have written on your page (while very good
information) is an exception to a rule and not a rule in and of itself.

Absolutely not - do you really think the above is an exception? Do you
think there's a single .NET application in the world which doesn't have
any value types in reference types?

I've never really heard of anyone being confused by this.

Do you want me to find the posts where people have been confused by
this? I distinctly remember them. They were the reason I wrote the page
in the first place. It would take me a while to find them, but I can if
you want. Or are you going to trust me?

Not only do some people find it confusing, but it doesn't explain the
bigger picture, either - it doesn't explain where the references
themselves live, or anything like that.

My explanation is:

1) Simple
2) Fairly complete
3) Correct

It helps people understand parameter passing and garbage collection
too.

Essentially we are saying that in cases where structures contain
reference types, they will be stored on the heap, rather than the
stack. Which, if you think about it, follows what I said originally
(reference types are stored on the heap).

No, that's not what I'm saying at all. It's where reference types
contain value types, not the other way round.

 

[Stephanie_Stowe]

That was the clearest answer. Thanks. I got a bit confused by reference
types and value types discussion later in the thread. I will do the
reading you suggest. This is tickling at my understanding. Tomorrow will
be the day it becomes firm.

Sorry for placing this in without context. My new newsreader does not
include.

S

 

[Jon Skeet [C# MVP]]

Do you want me to find the posts where people have been confused by
this? I distinctly remember them. They were the reason I wrote the page
in the first place. It would take me a while to find them, but I can if

I've found a few fairly simply:

http://groups.google.com/groups?threadm=MPG.1993092ec25591898a235%
40news.microsoft.com

http://groups.google.com/groups?threadm=MPG.1aee13ee903513b498a6da%
40msnews.microsoft.com

http://groups.google.com/groups?threadm=MPG.1ac3a6c9eea49d5c98a41b%
40msnews.microsoft.com

(watch for wrapping)

Not all of these people admit that they were confused - some do, some
don't - but they've bought into the idea that value types are only ever
stored on the stack, which is simply isn't true. I don't believe that
they would have made the incorrect statements had it been explained to
them properly in the first place, instead of with incorrect
"simplifications" such as the one you made.

 

[Scott M.]

Well Jon, you are obviously very passionate about your position. And, while
I don't dispute what you are saying, I think you are simply extending what I
said.

If you take a "pure" structure (one that simply stores value types),
then the explanation is valid.

Only if that structure is never part of a reference type.

Right, and this is just a clarification of the point, not a refutation of
it.

 

[Jon Skeet [C# MVP]]

Well Jon, you are obviously very passionate about your position.

Absolutely. I don't like people spreading misinformation, as it leads
to more people being confused. You'll find I'm equally passionate about
other things people are often incorrect about. For example:

o What pass-by-reference semantics really are
o How many characters are in ASCII
o The nature of floating point calculations and the decimal type
o How much exceptions *really* affect performance

And, while I don't dispute what you are saying, I think you are
simply extending what I said.

No, I'm correcting the incorrect implication of it.

Only if that structure is never part of a reference type.

Right, and this is just a clarification of the point, not a refutation of
it.

You said that value types are allocated on the stack, and reference
types are allocated on the heap.

Value types are *sometimes* allocated on the stack, but are often
allocated on the heap. While you didn't explicitly say that they're
*always* allocated on the stack, that's the clear implication - it's
certainly what many people have inferred from similar statements in the
past.

Your statement was at best misleading - its implications are incorrect.
I've shown in another post how people have been misled by such
statements in the past.

If you claim it doesn't imply that stack types aren't allocated on the
heap, your statement leaves the possibility that reference types are
sometimes allocated on the stack just as open. In other words, if you
remove the implications, it becomes almost worthless as a statement.

Are you seriously trying to claim that you *didn't* imply that all
value type values are allocated on the stack? Suppose someone said to
you:

"Reference types derive from the System.Exception type."

Would you not quibble with them, saying that while *some* reference
types derive from the System.Exception type, others do not? Would you
not infer that they were claiming that *all* reference types derive
from the System.Exception type? If so, how is your statement that
"Value Types are stored in memory on the Stack" any different?

 

[Scott M.]

Jon,

My explanation is a bottom up explanation. In that, at the lowest level in
..NET, you have a "type", that type is either a reference type or a value
type.

My explanation is referring to "pure" value types, not value types that are
members of a reference type. My statement, despite what you say, is correct
for this scenario. Your statement is correct for the scenario that you are
describing, But I would say that you are giving a top-down explanation,
which is not the approach that I take.

 

[Jon Skeet [C# MVP]]

My explanation is a bottom up explanation. In that, at the lowest
level in .NET, you have a "type", that type is either a reference
type or a value type.

That much is certainly true.

My explanation is referring to "pure" value types, not value types
that are members of a reference type.

An int is an int, whether it's a member of a reference type or not.
It's still a pure value type. Consider an int variable which is a
member of a reference type. You've said about that types are either
reference types or value types - so what's the type of that variable?
Surely you're not going to claim it's a reference type? If it's not a
reference type, then it's a value type, right? And if it's a value
type, your statement implies it lives on the stack - whoops.

My statement, despite what you say, is correct for this scenario.

"This scenario" being solely local variables and members of a value
type which also happens to be on the stack. Pretty restrictive
scenario, don't you think? Shame you didn't mention that restriction in
the statement, preferring to leave it misleading.

Your statement is correct for the scenario that you are describing,
But I would say that you are giving a top-down explanation, which is
not the approach that I take.

Your explanation is confusing. (See links previously posted.) Mine
isn't. Yours also doesn't give any indication as to where references
themselves go, or what the value of a variable actually is.

What's the benefit of your explanation again, other than brevity? Why
would you choose to take an approach which has proven to confuse
people, and is only applicable to a very limited set of circumstances
(unmentioned in the explanation itself)?

Which explanation do you think actually leaves people with a more
accurate impression of the type system, and why? What false implication
might people get from my explanation? (I've explained the false
implication people *do* get from your explanation.)

 

[Scott M.]

What's the benefit of your explanation again, other than brevity? Why

would you choose to take an approach which has proven to confuse
people, and is only applicable to a very limited set of circumstances
(unmentioned in the explanation itself)?

Which explanation do you think actually leaves people with a more
accurate impression of the type system, and why? What false implication
might people get from my explanation? (I've explained the false
implication people *do* get from your explanation.)

This will be my last post in this thread, but as a professional trainer, who
has trained literally over 10,000 people. I can certainly say without
hesitation something that those who have not taught to any great extent
wouldn't know; you must teach concepts before you can teach detail oriented
application of that concept.

Clearly, you and I have been having a conversation about 2 different things,
but I think from reading your posts, that you still haven't gotten that.
I've never disputed your point on if a value type can live on the heap, but
you fail to even come close to understanding what it is that I'm trying to
say.

In my 20 plus years of experience, there are certain approaches to mastering
a concept. If you'll remember the OP was a newbie. It is not always the
best idea to lay the most intricate details of something on someone who
needs to understand the concept first. If you go back and read this thread,
you'll see that the OP even acknowledged to another poster: "That was the
clearest answer. Thanks. I got a bit confused by reference types and value
types discussion later in the thread."

Despite what you've said, I will continue to approach the concept of
value/reference types to newbie's in the exact same successful manner that I
have been doing for several years now as I've found that this has been the
best way to get someone thinking about it clearly. When those students are
ready to move to a level of greater understanding of memory management and
OO concepts, they are ready for what you have been addressing.

Thank you for bringing your detailed knowledge of the subject into the
conversation.

Regards,

-Scott

 

[Jon Skeet [C# MVP]]

This will be my last post in this thread

Fair enough - but I'd be interested in continuing this by email if
you're willing. I'm passionate about trying to get people who teach
other people not to teach them falsehoods that other people then have
to correct later on. I'd like a bit more time to try to convince you

but as a professional
trainer, who has trained literally over 10,000 people. I can
certainly say without hesitation something that those who have not
taught to any great extent wouldn't know; you must teach concepts
before you can teach detail oriented application of that concept.

You might be interested to hear that various people have emailed me or
posted on the newsgroups stating that they've found my page has helped
them understand things which had previously confused them.

As for "those who have not taught to any great extent wouldn't know" -
I believe my pages *do* teach people, as do my newsgroup posts. I may
not be a professional trainer, but that doesn't mean I haven't taught
or don't know how to teach. (If you want to trade numbers, use
groups.google.com. My C# pages receive between four and five thousand
hits a week. They wouldn't do that if they didn't teach people stuff,
surely?)

Furthermore, I think that understanding the difference between a value
type and a reference type is hindered rather than helped by the kind of
statement you made. Instead, talk about the difference between a
reference and an object; that the value of any reference type
expression is a reference and not an object. Once you've got that, you
can easily move onto the fact that where a variable's value goes
depends only on its context (local variables always being on the stack,
etc) and that objects themselves go on the heap.

As for teaching the concept before the detail oriented application -
which would you count your statement as? My article is fairly brief
about the difference between value types and reference types, but it
does cover it. (I keep meaning to write a full article talking about
just that topic, and then referencing it from both the memory and
parameter passing articles, but I haven't got round to it yet.)

Clearly, you and I have been having a conversation about 2 different
things, but I think from reading your posts, that you still haven't
gotten that.

I've "got" that you seem to think that teaching people something which
isn't true is a good idea in this case, whereas I've shown clear
evidence that people *do* get confused by it. You still haven't
commented on that, as far as I've seen.

I've never disputed your point on if a value type can live on the heap, but
you fail to even come close to understanding what it is that I'm trying to
say.

You've claimed that what you said was correct, despite now
acknowledging that value types can live on the heap. Do you deny that
what your statement implies is *not* correct?

I still find it amazing that you said that the information on my page
was the "exception to the rule and not a rule in and of itself". What
proportion of types do you create which don't contain value type
variables? My page explains *the* rule, to which there are no
exceptions (unless you count the possibility of a future JIT moving
things around, putting objects on the stack if it knows they're not
used after the method finishes etc) as far as I'm concerned. If you
think there are exceptions, please state them - otherwise in what way
is it not a rule in and of itself?

In my 20 plus years of experience, there are certain approaches to mastering
a concept. If you'll remember the OP was a newbie. It is not always the
best idea to lay the most intricate details of something on someone who
needs to understand the concept first.

I agree, but only if you can give basics *without* actually saying or
implying things which aren't true, as you do here. Also I only agree if
explaining things properly is either difficult or makes other things
more complicated.

In this case it's not particuarly difficult to understand, and it helps
greatly in other areas. How can anyone understand parameter passing or
even basic variable assignment if they don't understand what a variable
actually holds?

If you go back and read this thread, you'll see that the OP even
acknowledged to another poster: "That was the clearest answer.
Thanks. I got a bit confused by reference types and value types
discussion later in the thread."

Indeed - it's not clear whether or not he'd have been confused if there
hadn't been two different messages presented, of course. You can't use
that quote to claim that your statement is less confusing than mine, as
it doesn't distinguish between the two.

Despite what you've said, I will continue to approach the concept of
value/reference types to newbie's in the exact same successful manner
that I have been doing for several years now as I've found that this
has been the best way to get someone thinking about it clearly.

Oh great. I wonder if I'll see some of those students ask questions in
the newsgroup based on the false implications of your statement, as
others who've been taught with statements such as yours have had to ask
in the past.

When those students are ready to move to a level of greater
understanding of memory management and OO concepts, they are ready
for what you have been addressing.

But it's really not that hard to start with! Teaching the truth about
variables and memory to start with isn't complicated, and makes so many
things easier. It always amazes me that some people try to write
Windows Forms applications, talk to databases, etc without really
understanding the difference between reference types and value types,
or what a variable really is.

 

[Jon Skeet [C# MVP]]

<snip>

Scott and I are now discussing this on email, but as a post-script to
this thread, I'd like to offer Scott a public apology for the
undeserved attacks on his classroom teaching skills. I recognise that
in a classroom, one has the opportunity to correct any mistaken
impressions left by an overly-general statement. I personally wouldn't
teach types in this way even in a classroom, but I acknowledge that if
he comes back to the topic later in a course, Scott needn't leave any
doubt in his students minds.

I still believe it's a dangerous statement to make in a newsgroup post,
however, with no caveats about its applicability. I believe it can lead
to the kind of confusion I've seen before. In a newsgroup setting, we
don't have the luxury of knowing that the reader will be available for
the slightly more detailed explanation later - instead, I believe it's
best to make sure that if statements we make are generalisations which
aren't true in all situations, we make that clear in the same post. In
this particular case, I see no reason not to explain the true general
case from the start.

As Scott noted, this is a topic I feel passionately about. However,
that is no excuse to overstep the mark as I did in this thread, for
which I apologise again.