Difference between nullable class and nullable<> structure

[Raj]

What is the difference between nullable class and nullable<> structure?

Thank you

Regards
Raj

 

[Family Tree Mike]

What is the difference between nullable class and nullable<> structure?

Thank you

Regards
Raj

I believe the answer to this and your previous question, "Details
needed" is the same. SomeClass? and nullable<SomeClass> are identical.

From link: http://msdn.microsoft.com/en-us/library/1t3y8s4s.aspx

"The syntax T? is shorthand for System.Nullable<T>, where T is a value
type. The two forms are interchangeable."

 

[Scott M.]

What is the difference between nullable class and nullable<> structure?

Thank you

Regards
Raj

Classes are reference types and are allocated onto the heap with a variable
pointing to them from the stack. As such you can indicate that you want to
"de-reference" your object, by setting the variable to null:

StreamReader sr = New StreamReader("file path");
sr = null;

Now, the StreamReader will still be in memory, but the "sr" variable no
longer points to it.

A structure is a value type and is allocated on the stack. Structures
cannot have a null value by definition so this wouldn't work:

Short x = 10;
x = null;

A value type *must* have a value - - it cannot be null. The C# compiler
will either assign a default value to a value type or expect you to do it,
but either way a value type must have a value.

..NET Generics helps you work as if you have a value type that can, in fact,
be null by creating a special class that holds value types, but because it's
a class, null can be used:

nullable<Short>

-Scott

 

[Peter Duniho]

Classes are reference types and are allocated onto the heap with a
variable
pointing to them from the stack.

"Heap" and "stack" have very little to do with "reference type" and "value
type". It's true that no reference types are ever allocated on the
stack. But most instances of value types are also not allocated on the
stack. And it's definitely not true that reference types always have "a
variable pointing to them from the stack". Most often, instances of
reference types are referenced only by member variables of instances of
other types.

Any discussion of reference types and value types that begins by
mentioning the heap and the stack is, at a minimum, bound to fall short of
precision, and at worst will be extremely misleading.

Please don't do that.

As such you can indicate that you want to
"de-reference" your object, by setting the variable to null:

StreamReader sr = New StreamReader("file path");
sr = null;

The word "dereference" has a very specific meaning in programming: to
access a data structure via a pointer (or "reference") to the data
structure. Please do not use the same word to mean something else.
Again, it will only confuse the discussion. (For example, see
http://en.wikipedia.org/wiki/Dereference)

Now, the StreamReader will still be in memory, but the "sr" variable no
longer points to it.

A structure is a value type and is allocated on the stack.

A structure is a value type, but it is absolutely not true that all
structures (or value types generally) are allocated on the stack. Please
don't say that.

Structures
cannot have a null value by definition so this wouldn't work:

Short x = 10;
x = null;

A value type *must* have a value - - it cannot be null. The C# compiler
will either assign a default value to a value type or expect you to do
it,
but either way a value type must have a value.

True. But to be clear, for a _local_ variable, the compiler will never
assign a default value implicitly. All local variables are required to be
explicitly assigned by the code before use.

In fact, ironically, the only time the compiler will assign a default
value to a value type is when it's contained as a member variable of a
reference type (either directly, or indirectly as part of another value
type that is so-contained), which directly contradicts your statement that
"a structure...is allocated on the stack".

.NET Generics helps you work as if you have a value type that can, in
fact,
be null by creating a special class that holds value types, but because
it's
a class, null can be used:

nullable<Short>

Also incorrect. The Nullable<T> type is a value type itself (it's a
struct). It simply happens to be usable as if it had reference type
semantics for the purpose of nullability.

Also note that it's not generics per se that provide this functionality.
It happens that the implementation does make use of generics, but it could
have been done without (albeit in a much more awkward way). The important
aspect of the implementation is the ability in the language to implicitly
treat that particular value type as if it were a reference type, solely
with respect to the purpose of nullability (note that because Nullable<T>
is a struct, it still behaves as a value type in every other way).

Pete

 

[Scott M.]

"Heap" and "stack" have very little to do with "reference type" and "value
type". It's true that no reference types are ever allocated on the
stack. But most instances of value types are also not allocated on the
stack. And it's definitely not true that reference types always have "a
variable pointing to them from the stack". Most often, instances of
reference types are referenced only by member variables of instances of
other types.

Any discussion of reference types and value types that begins by
mentioning the heap and the stack is, at a minimum, bound to fall short of
precision, and at worst will be extremely misleading.

Please don't do that.

For the purposes of explaining why reference types can be null and value
types can't the explanation is sufficient. Please don't tell me how I
should explain my own point.

The word "dereference" has a very specific meaning in programming: to
access a data structure via a pointer (or "reference") to the data
structure. Please do not use the same word to mean something else.
Again, it will only confuse the discussion. (For example, see
http://en.wikipedia.org/wiki/Dereference)

I know exactly how the term is used and my use of it is perfectly correct.
Again, it is not for you to police other people's explanations.

A structure is a value type, but it is absolutely not true that all
structures (or value types generally) are allocated on the stack. Please
don't say that.

Again, the explanation is sound and you should not feel that you need to ask
others to "please" change the way they explain things to suit your
preferences. I have not said that all value types are always allocated on
the stack.

True. But to be clear, for a _local_ variable, the compiler will never
assign a default value implicitly. All local variables are required to be
explicitly assigned by the code before use.

Yep, that's why I said that the C# compiler will either do it or expect you
to do it.

 

[Peter Duniho]

For the purposes of explaining why reference types can be null and value
types can't the explanation is sufficient.

No, it's not. Your statement makes the claim that an instance of a
reference type is "pointed to...from the stack". This is not a
universally true statement. Nor is your later claim that all structures
are allocated on the stack.

Please don't tell me how I should explain my own point.

You may explain your point any way you like, as long as you state only
true statements. Once you fail to do that, you should not be surprised to
be corrected, and you have no standing to ask others not to correct you.

As such you can indicate that you want to
"de-reference" your object, by setting the variable to null: [...]

The word "dereference" has a very specific meaning in programming: to
access a data structure via a pointer (or "reference") to the data
structure. [...]

I know exactly how the term is used and my use of it is perfectly
correct.
Again, it is not for you to police other people's explanations.

You can use the word however you like. But do not be surprised when
people don't have any idea what you're talking about. Your usage is
absolutely non-standard, in spite of your opinion that it's "perfectly
correct". There isn't a single mainstream programming reference that uses
the term "dereference" to mean "set to null".

And again, if you use it in this non-standard way, you should not be
surprised to be corrected, nor do you have any standing to ask others not
to correct you.

Again, the explanation is sound and you should not feel that you need to
ask
others to "please" change the way they explain things to suit your
preferences.

I have written "please" because I know from past experience that you have
a very difficult time accepting any sort of disagreement or correction,
even when your statements are plainly wrong. It's an attempt to be gentle
about my corrections, so that perhaps you can be more accommodating.

But the fact is, your statements conflating the stack and value types are
simply wrong. Period. Your explanation is quite far from being "sound".
If you prefer that I stop using the word "please", so be it. I won't
waste any more time trying to be polite on this matter.

This isn't about "my preferences". It's about what is factually and
demonstrably correct. It's true, it's my preference that people not make
false statements. But my goal here is not to express that preference, but
rather to correct those false statements. I attempted to be kind about
it, so as to avoid you getting your hackles up, but obviously I failed in
that regard. No matter...that wasn't my primary goal. My primary goal
was to get the correct facts documented as part of this thread, and I've
done that.

I have not said that all value types are always allocated on
the stack.

You wrote "a structure is a value type and is allocated on the stack".
How else is anyone to interpret that statement, than to mean "all
structures are value types, and thus all structures are allocated on the
stack, just as all value types are"?

An unqualified statement regarding "a structure" is semantically the same
as being a statement about "all structures", and the phrasing of the
statement clearly describes an (incorrect) assertion that structures are
always allocated on the stack as being by virtue of structures being value
types, thus meaning that all value types are always allocated on the stack.

At a minimum, you have clearly and unequivocally stated that "all
structures are always allocated on the stack", which is wrong, even if you
didn't mean to include all value types in the statement. And of course,
there aren't any value types in C# that aren't structs. Even something
like "int" is actually "System.Int32", which is a struct (i.e. "a
structure"...itself an incorrect usage of the word "structure", as classes
are "structures" too; "struct" is not synonymous with "structure").

Fortunately, at this point it really doesn't matter what you wrote, or
follow-up by writing. Anyone reading this thread will understand that
there is a disagreement as to the proper interpretation of reference types
and value types, and will consult the documentation (for example,
http://msdn.microsoft.com/en-us/library/system.valuetype.aspx, where one
can read "Value types are either stack-allocated or allocated inline in a
structure" -- i.e. they are sometimes not stack-allocated -- or even
better, the C# and CLR specifications, that discuss reference and value
types in a more precise way). There, they will find that certain
statements of yours (not all, of course) about reference types and value
types are wrong and that mine are right.

For that matter, if they read carefully, they may even note that the
concept of "stack" doesn't pertain to C# or .NET at all. There is no
requirement that local variables be implemented using a stack at all. Any
statement about the pure behavior of C# that includes the word "stack" is
bound to be wrong, because "stack" is an implementation detail, not part
of the C# or CLR specification.

Those interested on this latter point can read more on Eric Lippert's blog:
http://blogs.msdn.com/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx
http://blogs.msdn.com/ericlippert/a...ack-is-an-implementation-detail-part-two.aspx

Pete

 

[Scott M.]

No, it's not. Your statement makes the claim that an instance of a
reference type is "pointed to...from the stack". This is not a
universally true statement. Nor is your later claim that all structures
are allocated on the stack.

And, it's not universally false either. And, I did not say that ALL
structures are allocated on the stack. You are inserting words that I did
not use into my statements. Please don't do that.

You may explain your point any way you like, as long as you state only
true statements.

Actually, I may explain my point any way I like, period. It is not for you
to dictate how a point should be made.

Once you fail to do that, you should not be surprised to be corrected,
and you have no standing to ask others not to correct you.

I'm not asking you not to correct. I'm asking you not to ask others to post
in the way you would like them to.

As such you can indicate that you want to
"de-reference" your object, by setting the variable to null: [...]

The word "dereference" has a very specific meaning in programming: to
access a data structure via a pointer (or "reference") to the data
structure. [...]

I know exactly how the term is used and my use of it is perfectly
correct.
Again, it is not for you to police other people's explanations.

You can use the word however you like. But do not be surprised when
people don't have any idea what you're talking about. Your usage is
absolutely non-standard, in spite of your opinion that it's "perfectly
correct". There isn't a single mainstream programming reference that uses
the term "dereference" to mean "set to null".

All I can say to that is that your sources must be extemely limited, because
that is just incorrect.

And again, if you use it in this non-standard way, you should not be
surprised to be corrected, nor do you have any standing to ask others not
to correct you.


I have written "please" because I know from past experience that you have
a very difficult time accepting any sort of disagreement or correction,
even when your statements are plainly wrong. It's an attempt to be gentle
about my corrections, so that perhaps you can be more accommodating.

If you feel that you need to post a correction, do so. But, do not tell
others how they should post. I am a big boy and can take care of myself.
The NG's do not need police. Say what you want to say, but don't tell
others how to post.

But the fact is, your statements conflating the stack and value types are
simply wrong. Period. Your explanation is quite far from being "sound".
If you prefer that I stop using the word "please", so be it. I won't
waste any more time trying to be polite on this matter.

This isn't about "my preferences". It's about what is factually and
demonstrably correct. It's true, it's my preference that people not make
false statements. But my goal here is not to express that preference, but
rather to correct those false statements. I attempted to be kind about
it, so as to avoid you getting your hackles up, but obviously I failed in
that regard. No matter...that wasn't my primary goal. My primary goal
was to get the correct facts documented as part of this thread, and I've
done that.

A) Here's how you correct a statement: "You said x earlier. That's wrong
it's y."

B) Here's how you become the NG police "Please don't post (fill in the
blank)".

No one is complaining about A, it's the B I take issue with, which has
nothing to do with facts at all. It has to do with how you would like posts
to be made.

You wrote "a structure is a value type and is allocated on the stack".
How else is anyone to interpret that statement, than to mean "all
structures are value types, and thus all structures are allocated on the
stack, just as all value types are"?

An unqualified statement regarding "a structure" is semantically the same
as being a statement about "all structures", and the phrasing of the
statement clearly describes an (incorrect) assertion that structures are
always allocated on the stack as being by virtue of structures being value
types, thus meaning that all value types are always allocated on the
stack.

At a minimum, you have clearly and unequivocally stated that "all
structures are always allocated on the stack", which is wrong, even if you
didn't mean to include all value types in the statement.

I disagree with your interpretation, but it's yours to make.

 

[Göran Andersson]

What is the difference between nullable class and nullable<> structure?

Thank you

Regards
Raj

A class is a reference type, so as it has a reference it is nullable by
nature. By assigning the null value to the reference you have a
reference that indicates a type, but it's not pointing to an instance of
that type.

A value type can not be nullable in that way, so the nullable<T>
structure was introduced to easily make a value type that can also hold
a null state. The nullable structure simply contains a boolean flag
along with the value, and the flag determines if the value should be
considered to be in existance or not. If the flag is false, the
structure prohibits you from accessing the value, making it work similar
to how a null reference works.

 

[Gregory A. Beamer]

Any discussion of reference types and value types that begins by
mentioning the heap and the stack is, at a minimum, bound to fall
short of precision, and at worst will be extremely misleading.

In the realm of being absolutely correct, I would agree with your
statements, but we often deal in analogies rather than absolutes when
teaching other developers.

The heap, in general, is open memory, while the stack is program memory.
Now, anyone who has programmed for a good length of time will note that
this statement is not absolutely 100% correct and possibly even
misleading, but it is very useful when explaining why a person who
writes only structures (for speed?) and no classes is more apt to end up
with an out of stack memory condition in his program because he heard
that structures are faster.

Then we have the statement that structures are faster. This is true in
general, but we also know that it is not always true and it is a bad
practice to only code in structures.

My point here is I don't see that Scott's statements are absolutely
dangerous, but would agree, as a compromise, that the statements should
have a disclaimer.

I often add disclaimers to my statements so we can avoid these
"technically you are incorrect" type of statements when the user wants
to know how to prevent his ice cream from melting and I don't want to
explain the complete nature of refrigeration. ;-)

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Gregory A. Beamer]

Excellent stuff, as is usual with Eric's writing...

Very nice article(s) on the details. I am going to bookmark that for the
future. ;-)

As for the stack and heap discussion, er fight, here: When we are first
taught the atomic structure, the solar system is often used as an
analogy, without disclaimers. It helps the young student understand
electrons and orbits. Technically, however, it is a flawed analogy,
which is learned later on. In the same boat, using stack and heap as a
general way of describing value and reference types, especially to
junior devs, does not bother me as much as it might some. It helps wrap
the mind around the concept, even if it is not true in all conditions,
just as undestanding you are working with the value (value type) versus
a reference to the "value" works on a basic level. I am sure someone
here might disagree, which is their prerogative. ;-)

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Peter Duniho]

[...]
As for the stack and heap discussion, er fight, here: When we are first
taught the atomic structure, the solar system is often used as an
analogy, without disclaimers. It helps the young student understand
electrons and orbits.

In what way? If the student already understand planetary orbital
mechanics, what knowledge there helps them understand atomic structure?
Are electrons kept in their orbits by gravity? Do they follow regular
elliptical paths? Are some electrons larger or smaller than others? Do
some electronics take more or less time to complete an orbit than
others? Do the protons and neutrons in the nucleus of an atom orbit
each other, again kept in proximity by gravity, but from collision by
velocity?

I won't dispute that some teachers introduce the solar system as an
analogy for atomic structure. However, I will certainly debate the
claim that doing so is actually helpful to the students. There's
practically nothing about the analogy that helps a student
better-comprehend atomic structure.

Technically, however, it is a flawed analogy,
which is learned later on. In the same boat, using stack and heap as a
general way of describing value and reference types, especially to
junior devs, does not bother me as much as it might some. It helps wrap
the mind around the concept, even if it is not true in all conditions,

It's not true in _any_ conditions. The things that make value types
different from reference types and interesting as a particular kind of
data structure don't have anything to do with the stack. It's simply a
convenience of purpose that value types _sometimes_ wind up on the
stack. Knowing that value types occasionally wind up actually stored on
the stack doesn't provide any insight whatsoever into the things that
make value types useful or unique.

just as undestanding you are working with the value (value type) versus
a reference to the "value" works on a basic level. I am sure someone
here might disagree, which is their prerogative. ;-)

It is a well-established educational principle that misdirecting the
student in this fashion is counter-productive. Using a false analogy
provides them no useful information in understanding the concept, as
compared to simply providing a simplified-but-correct explanation, and
it leads to the student failing to properly comprehend the more detailed
concepts.

See http://en.wikipedia.org/wiki/Principles_of_learning#Primacy for more
details.

It's well and good to, when introducing the idea of a "value type" to a
student, to limit the information about that idea to the things the
student is capable of comprehending at that moment. I'd argue that
value types aren't really all that complicated and that there's no real
need to limit that information, but every student is different and if
there's a need, fine. But to teach the student WRONG information as a
substitute for teaching them correct information is misguided at best,
disrespectful and irresponsibly deficient at worst.

Pete

 

[Peter Duniho]

[...]
The heap, in general, is open memory, while the stack is program memory.
Now, anyone who has programmed for a good length of time will note that
this statement is not absolutely 100% correct and possibly even
misleading, but it is very useful when explaining why a person who
writes only structures (for speed?) and no classes is more apt to end up
with an out of stack memory condition in his program because he heard
that structures are faster.

IMHO, at best you are proving my point and at worst, you are making
things worse with respect to comprehending value types.

The use of structs (not structures...classes are structures too) is
unlikely to cause "an out of stack memory condition". Programs require
persistent data in order to do useful work; the likelihood of that
persistent data to be stored on the stack is incredibly low, because of
the sheer impracticality of doing so.

For a program using exclusive structs as the user-defined types to have
the persistent instances of those structs allocated on the stack, you'd
have to make a new method call for each object you want to allocate, and
that method would have to not return until you no longer need that
object. In addition, you'd still need a way to reference that object,
which means passing the object as "ref" to each called method; every new
object allocated means a new "ref" argument to the method argument list
(not counting approaches that might use unsafe code).

Granted, if you wrote a program this way, it probably would have a stack
overflow exception. But the exception would be caused not by the
structs actually stored on the stack as local variables, but by all the
arguments getting passed with each method call (in any non-trivial
program, the argument lists could number in the hundreds, or even
thousands, of arguments, if not more).

In fact, you are demonstrating exactly the kind of fallacy that leads
from conflating value types and the stack. Most of the time, a value
type is still allocated in the heap. It's either inline with another
data structure (that is eventually contained a reference type), or it's
in an array of that value type (and of course arrays in C# are always
reference types). A person who thinks that the use of structs instead
of classes is going to cause a stack-overflow exception has
misunderstood what's special about a value type and the implications of
structs on program execution.

Then we have the statement that structures are faster. This is true in
general, but we also know that it is not always true and it is a bad
practice to only code in structures.

Yes, it can be true that structs can be faster. But this doesn't have
anything to do with the use of the stack versus the heap, and it is
simple to teach a person learning about value types to say that structs
can be faster in some cases, and then to explain those cases. The word
"stack" never has to come up.

Certainly the fact that it's possible to state some other incorrect
thing about value types (i.e. "structs are always faster") doesn't
justify stating the earlier incorrect thing about value types (i.e.
"structs are always on the stack").

My point here is I don't see that Scott's statements are absolutely
dangerous, but would agree, as a compromise, that the statements should
have a disclaimer.

I often add disclaimers to my statements so we can avoid these
"technically you are incorrect" type of statements when the user wants
to know how to prevent his ice cream from melting and I don't want to
explain the complete nature of refrigeration. ;-)

A more correct analogy would be a user who wants to know how to prevent
his ice cream from melting being told that because they live in Alaska,
they can simply store their ice cream out on the back porch and it will
stay frozen no matter what time of the year it is.

Pete

 

[Scott M.]

The following comes from "Pro VB 2005 and the .NET 2.0 Platform", APress, by
Andrew Troelsen

Page 313 (Understanding Value Types and Reference Types):

"Specifically speaking, a .NET data type may be value-based or
reference-based. Value-based types, which include all numerical data types
(Integer, Double, etc.), as well as enumerations and structures, are
allocated on the stack."

Point #1:

Realizing that this is a C# NG, but also realizing the Greg used the VB .NET
term "structure", let me quote from page 123 (Programming Constructs):

"...structures do not have an identically named class representation in the
..NET library (that is there is no System.Structure class), but are
implicitly derived from System.ValueType."

and from page 314:

"...understand that .NET structures and enumerations are also value types.
Structures, as you may recall from Chapter 4, provide a way to achieve
bare-bones benefits of object orientation (i.e. , encapsulation) while
having the efficiency of stack-allocated data."

Your statement to Greg that the term "structure" to refer to a value type
was incorrect, is itself incorrect.

Point #2:

You stated:

"Any discussion of reference types and value types that begins by mentioning
the heap and the stack is, at a minimum, bound to fall short of precision,
and at worst will be extremely misleading."

The author (who you may have heard of and is considered to be quite an
expert in .NET) explains value-types to the reader in just the same way I
did. In fact, this approach is also taken in "Professional Visual Basic
2008", WROX. And, in fact, it is taken in just about every text I can find
on the subject.

The bottom line for me Peter is that you may know quite a bit about
programming, but you know very little about teaching and despite your edicts
on what teaching technique is "at best" and "at worst" as have been "proven"
as unreliable, every single one of those assertions is absolutely wrong when
it comes to IT Education.

Those who can't teach cite Wikipedia, those who can, do.

My 20 years of experience in IT Education clearly contradicts your several
minutes of Wikipedia searching and conclusions based on no actual experience
in teaching.

Despite what you may personally belive, I (and just a few notable others)
feel that it is appropriate to discuss reference and value types in the
context of the stack and the heap and that it is not necessary to explore
all the gory details during the initial exposure to the concepts.

There's just no argument you can put up to defend youre point, other than
your opinion.

-Scott

[...]
As for the stack and heap discussion, er fight, here: When we are first
taught the atomic structure, the solar system is often used as an
analogy, without disclaimers. It helps the young student understand
electrons and orbits.

In what way? If the student already understand planetary orbital
mechanics, what knowledge there helps them understand atomic structure?
Are electrons kept in their orbits by gravity? Do they follow regular
elliptical paths? Are some electrons larger or smaller than others? Do
some electronics take more or less time to complete an orbit than others?
Do the protons and neutrons in the nucleus of an atom orbit each other,
again kept in proximity by gravity, but from collision by velocity?

I won't dispute that some teachers introduce the solar system as an
analogy for atomic structure. However, I will certainly debate the claim
that doing so is actually helpful to the students. There's practically
nothing about the analogy that helps a student better-comprehend atomic
structure.

Technically, however, it is a flawed analogy,
which is learned later on. In the same boat, using stack and heap as a
general way of describing value and reference types, especially to
junior devs, does not bother me as much as it might some. It helps wrap
the mind around the concept, even if it is not true in all conditions,

It's not true in _any_ conditions. The things that make value types
different from reference types and interesting as a particular kind of
data structure don't have anything to do with the stack. It's simply a
convenience of purpose that value types _sometimes_ wind up on the stack.
Knowing that value types occasionally wind up actually stored on the stack
doesn't provide any insight whatsoever into the things that make value
types useful or unique.

just as undestanding you are working with the value (value type) versus
a reference to the "value" works on a basic level. I am sure someone
here might disagree, which is their prerogative. ;-)

It is a well-established educational principle that misdirecting the
student in this fashion is counter-productive. Using a false analogy
provides them no useful information in understanding the concept, as
compared to simply providing a simplified-but-correct explanation, and it
leads to the student failing to properly comprehend the more detailed
concepts.

See http://en.wikipedia.org/wiki/Principles_of_learning#Primacy for more
details.

It's well and good to, when introducing the idea of a "value type" to a
student, to limit the information about that idea to the things the
student is capable of comprehending at that moment. I'd argue that value
types aren't really all that complicated and that there's no real need to
limit that information, but every student is different and if there's a
need, fine. But to teach the student WRONG information as a substitute
for teaching them correct information is misguided at best, disrespectful
and irresponsibly deficient at worst.

Pete

 

[Peter Duniho]

[...]
Your statement to Greg that the term "structure" to refer to a value type
was incorrect, is itself incorrect.

Hardly. In the context of C# (which is, of course, the current
context), my statement was quite accurate. Go read the C# specification
if you don't believe me. A VB.NET reference offers no insight
whatsoever into the question.

Why you're even bothering to comment on this point, I have no idea. I
have happily ignored the mis-use of the word "structure" in most of this
discussion, regarding it as a pointless distraction from the real meat
of the question. I mentioned it only in my _other_ reply to Gregory,
because a) I felt he'd be amenable to the hair-splitting (not everyone
is, as you may be aware), and b) because in my estimation it added
something to that particular moment in the discussion.

Point #2:

You stated:

"Any discussion of reference types and value types that begins by mentioning
the heap and the stack is, at a minimum, bound to fall short of precision,
and at worst will be extremely misleading."

Yes, I did. A correct statement.

The author (who you may have heard of and is considered to be quite an
expert in .NET) explains value-types to the reader in just the same way I
did. In fact, this approach is also taken in "Professional Visual Basic
2008", WROX. And, in fact, it is taken in just about every text I can find
on the subject.

I have not heard of that author, but even if I did, I don't care. Even
if he is an expert in .NET, that doesn't mean he knows the best way to
communicate his knowledge to others, and frankly it doesn't even mean
that he actually has a complete and accurate understanding of value
types in .NET.

Any statement that implies that all value types are stack-allocated is
wrong. And any statement that mentions the stack and value types in the
same sentence without being very clear that value types are allocated on
the stack only in a very specific scenario (i.e. when there's a local
variable having the value type as its declared type), rather than
always, makes just that implication.

And unfortunately, most of the time someone makes that implication, it's
not because they've simply glossed over the question. It's because they
actually _don't know_ how value types work. In fact often, when they
are confronted by the facts of the matter, they will attempt to hide
their prior failure of knowledge by asserting that they were simply
"making things simple" and then entering in a protracted debate as to
whether making false statements in the pursuit of simplicity is an
effective teaching tool or not.

The bottom line for me Peter is that you may know quite a bit about
programming, but you know very little about teaching and despite your edicts
on what teaching technique is "at best" and "at worst" as have been "proven"
as unreliable, every single one of those assertions is absolutely wrong when
it comes to IT Education.

That's quite a brazen claim to make. Quite wrong, of course. But you
are welcome to your uninformed opinion.

Those who can't teach cite Wikipedia, those who can, do.

Are you suggesting that making reference to well-established facts is
not a useful exercise in a discussion? If so, I am beginning to see why
you are having so much trouble with this.

My 20 years of experience in IT Education clearly contradicts your several
minutes of Wikipedia searching and conclusions based on no actual experience
in teaching.

If the extent of my experience was "several minutes of Wikipedia
searching", there _might_ have been a _smidgen_ of truth to your accusation.

But that's a false premise, so whatever conclusion comes from it is
useless. How about you try making fewer ASSumptions about what
experience I do and do not have?

And even if I take as granted that you have spent a full 20 years
teaching others in the IT industry, that means very little. It is much
easier to find a bad teacher than a good one. The odds are not in your
favor, if we base your qualifications (or mine) solely on the length of
time spent teaching.

Despite what you may personally belive, I (and just a few notable others)
feel that it is appropriate to discuss reference and value types in the
context of the stack and the heap and that it is not necessary to explore
all the gory details during the initial exposure to the concepts.

I have never said it was. I simply have stated that one should not make
incorrect claims when teaching a subject.

A teacher has two valid choices when introducing the concept of value types:

-- Explain that value types are only sometimes allocated on the
stack, and other times allocated on the heap, and explain the
differences between those scenarios

-- Don't mention the stack at all

What a teacher may not do, if they intend to act responsibly, is make a
statement that will mislead a student into thinking value types are
always allocated on the stack.

Frankly, IMHO the second option -- don't mention the stack at all -- is
the correct one. The things that are most important to know about value
types have nothing at all to do with the stack. They have everything to
do with the semantics in the program and how value types are used in the
code.

Later, it is perfectly fine to introduce the more advanced and
implementation-specific details related to value types. After all,
that's part of a complete education. But none of those details are
important to the person just learning about value types.

But, if you feel absolutely compelled to mention the stack when
introducing the concept of value types, you have an obligation to
explain the full monty, and to avoid misleading or incorrect statements.

The key here is: don't teach false facts. They only have to be
unlearned by the student later.

There's just no argument you can put up to defend youre point, other than
your opinion.

Actually, I provided plenty of references to justify both my comments
about how value types work, as well as what the proper way of
introducing them to students are.

Where are your references? Or do you think is suffices to simply state
your own opinion and expect others to take it as fact?

Pete

 

[Scott M.]

[...]
Your statement to Greg that the term "structure" to refer to a value type
was incorrect, is itself incorrect.

Hardly. In the context of C# (which is, of course, the current context),
my statement was quite accurate. Go read the C# specification if you
don't believe me. A VB.NET reference offers no insight whatsoever into
the question.

No, you won't get off that easy Peter. You explicitly stated that
structured were not value types. They are, period.

Yes, I did. A correct statement.

No, a personal opinion.

I have not heard of that author, but even if I did, I don't care.

Well, that says a lot about your ability to be open-minded and see a point
from someone else's point of view. You just don't care. You're right and
no matter what anyone says, you're right.

Even if he is an expert in .NET, that doesn't mean he knows the best way
to communicate his knowledge to others, and frankly it doesn't even mean
that he actually has a complete and accurate understanding of value types
in .NET.

Perhaps, but since this is not the approach that just one author takes, it
is the approach that the vast majority of authors and teachers take when
introducing this topic, I find your opinion hardly substantiated.

Any statement that implies that all value types are stack-allocated is
wrong. And any statement that mentions the stack and value types in the
same sentence without being very clear that value types are allocated on
the stack only in a very specific scenario (i.e. when there's a local
variable having the value type as its declared type), rather than always,
makes just that implication.

This statement just bolsters my point that you don't have any practical
training in education.

And unfortunately, most of the time someone makes that implication, it's
not because they've simply glossed over the question. It's because they
actually _don't know_ how value types work. In fact often, when they are
confronted by the facts of the matter, they will attempt to hide their
prior failure of knowledge by asserting that they were simply "making
things simple" and then entering in a protracted debate as to whether
making false statements in the pursuit of simplicity is an effective
teaching tool or not.

Well, that's quite an implication of its own. An implication based on
nothing I might add. I could counter it with something like most of the
time someone is unwilling to budge the slightest amount and consider that
there may be more than one way to do something, they are usually ignorant.
But, it does not really address the point, it really is just an insult and
does not further the conversation.

That's quite a brazen claim to make. Quite wrong, of course. But you are
welcome to your uninformed opinion.

Yet you have nothing to defend your denial with. Listen, I'm in education
and people in the field know when they are talking with someone who isn't.
That's true in most professions. Every single statement you've made about
how to teach is NOT backed up by any successful teacher or teaching method.
I've provided you with evidence that mainstream technical manauals (more
than a few - I have at least seven on my bookshelf) present this information
in just the way I did. You've even heard from Greg (who has some background
in IT education), who concurs with me and yet you continue to dismiss it out
of hand. But, based on what? You've simply given your personal opinoin.

Are you suggesting that making reference to well-established facts is not
a useful exercise in a discussion? If so, I am beginning to see why you
are having so much trouble with this.

Not at all, what well-established facts do you have? Because you haven't
presented any. And to be clear, I'm not having any trouble with this. I'm
quite content in my explanation. I know from my experience that this
approach works quite well and I know that my students go on to understand
this topic quite clearly when they are ready to get to that level. I know
that countless textbooks wirtten by many well respected and knowledgeable
people from Dino Espisito to Bill Evjen, teach this topic the same way I do.
Yet, from the beginning here, it's been you that are having trouble with
this.

If the extent of my experience was "several minutes of Wikipedia
searching", there _might_ have been a _smidgen_ of truth to your
accusation.

It's quite obvious you have no formal training in education. Just as it
would be quite obvious to a physicist that I have no formal training in
Quantum Mechanics. Sure, I can talk superficially about it, but when the
conversation gets to the nitty gritty, it's clear who knows what they are
talking about and who doesn't. Peter, you've provided no evidence that you
have any knowledge about teaching. I have shown that the technique I use is
used by a LARGE amount of professionals, not only in IT Education by the
way, but in virtually ANY learning environment.

But that's a false premise, so whatever conclusion comes from it is
useless. How about you try making fewer ASSumptions about what experience
I do and do not have?

How about telling us what your experience is and why your approach is not
taken by the vast majority of people who teach this stuff?

And even if I take as granted that you have spent a full 20 years teaching
others in the IT industry, that means very little.

Only because you choose to ignore it.

It is much easier to find a bad teacher than a good one. The odds are not
in your favor, if we base your qualifications (or mine) solely on the
length of time spent teaching.

Perhaps, but by every measurement that I've been measured by (my students,
my peers, and my superiors), I know that my success isn't about "odds". You
can certainly dismiss someone with 20 years of experience trying to tell you
something about something you don't know or you can open your mind to
learning something you didn't know. Your out-of-hand dismissal really
screams of the dictionary definition of ignorance. You will not listen
because you do not want to listen. You said it yourself Peter, when I
provided you with several examples of well-known mainstream resources
addressing exactly this topic, you said: "I don't care." followed up with a
statement implying that they must be wrong.

I have never said it was. I simply have stated that one should not make
incorrect claims when teaching a subject.

It is NOT incorrect to say that value-types are allocated to the stack. It
may be an incomplete statement, I grant you, but it is NOT incorrect. In
fact, I would say that this statement is dead on textbook definition of
where value-types are stored and that when you encounter a value-type that
is used as a class field, that you are encountering a different situation,
wich causes the definition to need to be changed, for that circumstance.
But, to a newbie who may not even understand what a class level field is,
that WILL just confuse the concept.

A teacher has two valid choices when introducing the concept of value
types:

-- Explain that value types are only sometimes allocated on the stack,
and other times allocated on the heap, and explain the differences between
those scenarios

And what to do when a student raises their hand and asks what a class is?
Or a field? Or an instance?

-- Don't mention the stack at all

Which gives the students no understanding of the separation between a
variable and what the variable points to. It gives them no understanding of
the difference between what's referencing the reference type and why a
reference type is different than a value type. For teaching purposes (and I
defy you to point to any .NET book that differs with me on this), equating
value-types with the stack and reference-types to the heap when the types
are introduced is appropriate.

So, what we have is your 2 choices, both leading to either confusion or
inadequate knowledge. Perhaps, just perhaps, there's another way that
accompishes the learning objective?

What a teacher may not do, if they intend to act responsibly, is make a
statement that will mislead a student into thinking value types are always
allocated on the stack.

This is the smoking gun that I need to know that you don't have any
real-world experience teaching. Because honestly, Peter, this approach is
taken all the time in almost every beginner's learning environment. As a
matter of fact, I was listening to a lecture, just today, by a noted
physisist from the University of Connecticut on the physics of time-travel
and actually propped myself up in my seat when I noticed he did exactly the
same sort of thing that is done with new learners. He revisited a point he
had made earlier and said something to the effect of "Remember when I
mentioned earlier that Einstein said that the speed of light is absolute?
Well, if you want to undersand why my theory is justifyable, you'll need to
know that there's more to that story and as it turns out the speed of light
isn't constant, it's just our ability to measure it that is."

Now, the first time the speed of light is mentioned it is INCORRECTLY stated
that it's speed is constant. Later, once the rest of the important concepts
are laid down, it was revealed that this is not actually a correct
statement, but was used to lay the groundwork for the next step in learning.

You may not care about any of that, just as you didn't care about the other
evidence I provided you, but the simple FACTS are that when presenting
material that can be complex, divulging small amounts and revisiting the
topic later to complete the picture is mainstream.

Frankly, IMHO the second option -- don't mention the stack at all -- is
the correct one. The things that are most important to know about value
types have nothing at all to do with the stack. They have everything to
do with the semantics in the program and how value types are used in the
code.

Well, as you said, that's your opinion. Being such I can't tell you that
you are right or wrong. And, if you had simply stated your views as your
personal opinions, we wouldn't have had all this time to practice our typing
skills, but that's not what you've done. You've presented your obviously
limited experience in this matter as fact and not backed it up with
anything. When confronted with real world examples and others in this
thread that agree with me, you responded "I don't care."

Later, it is perfectly fine to introduce the more advanced and
implementation-specific details related to value types. After all, that's
part of a complete education. But none of those details are important to
the person just learning about value types.

Well, you've made a decision about what's important to know at the beginning
and what's not. I have taught .NET for about 40 different Fortune 1000
companies over the years and when working with them to determine what
concepts are important for their developers to know, they disagree with you.
As do the authors of every .NET book I've ever picked up. As do every other
instructor I've met that teaches this.

But, if you feel absolutely compelled to mention the stack when
introducing the concept of value types, you have an obligation to explain
the full monty, and to avoid misleading or incorrect statements.

See my Eisnstien comments.

The key here is: don't teach false facts. They only have to be unlearned
by the student later.

It is a fact that value-types are allocated on the stack. There are
circumstances that cause that default behavior to change, but that doesn't
change the default behavor.

Actually, I provided plenty of references to justify both my comments
about how value types work, as well as what the proper way of introducing
them to students are.

I was never disputing how value types work with you and you've provided no
proof of a "proper way" to teach the concept.

Where are your references? Or do you think is suffices to simply state
your own opinion and expect others to take it as fact?

Read this post and my immediate last one as I have provided several sources
that relate to this very topic (teaching value-types) as well as several
relating to teaching in general. The fact that you seem to have missed
them, makes me think that you put them in your "I don't care" vault.

-Scott

 

[Peter Duniho]

[...]
Well, that says a lot about your ability to be open-minded and see a point
from someone else's point of view. You just don't care. You're right and
no matter what anyone says, you're right. [...]

Just FYI: at this point, the third time in a just a handful of sentences
you've attempted to put words in my mouth, I've stopped reading. You
clearly don't care to carry on any semblance of a mature, factual
discussion.

 

[Scott M.]

[...]
Well, that says a lot about your ability to be open-minded and see a
point from someone else's point of view. You just don't care. You're
right and no matter what anyone says, you're right. [...]

Just FYI: at this point, the third time in a just a handful of sentences
you've attempted to put words in my mouth, I've stopped reading. You
clearly don't care to carry on any semblance of a mature, factual
discussion.

That's fine, but let's at least have the record clear. This is what my
reply above was based on, you saying:

" I have not heard of that author, but even if I did, I don't care."

I'm content to let anyone with enough time on their hands read this thread
and decide who's presented a mature, rational agrument with facts and who
hasn't.

-Scott

 

[Gregory A. Beamer]

I won't dispute that some teachers introduce the solar system as an
analogy for atomic structure. However, I will certainly debate the
claim that doing so is actually helpful to the students. There's
practically nothing about the analogy that helps a student
better-comprehend atomic structure.

I disagree, as mentally picturing something, even if not 100%
technically correct, often breaks someone through the paradigm shifts
necessary to understand the concept on a basic level.

The main question HERE is whether or not the OP gained understanding
through the simple stack/heap explanation or was confused, not whether
or not the answer wsa technically correct on a deeper level. I would
venture to guess the OP has long left this discussion and we are satting
flies on whether or not analogies are ever useful.

Regardless, this nitpicky "technically" thread is an absolute waste of
my time, so I will let the big boys continue to argue the minutia.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Peter Duniho]

[...]
I'm content to let anyone with enough time on their hands read this thread
and decide who's presented a mature, rational agrument with facts and who
hasn't.

Indeed. After all, one person here has made only factual statements and
provided specific Microsoft documentation supporting those statements,
while another person has chosen to defend their position almost entirely
on the basis of mis-characterization of the statements of the other and
use of personal insults.

It should be easy enough for even the casual observer to see which is which.

 

[Scott M.]

[...]
I'm content to let anyone with enough time on their hands read this
thread and decide who's presented a mature, rational agrument with facts
and who hasn't.

Indeed. After all, one person here has made only factual statements and
provided specific Microsoft documentation supporting those statements,
while another person has chosen to defend their position almost entirely
on the basis of mis-characterization of the statements of the other and
use of personal insults.

It should be easy enough for even the casual observer to see which is
which.

Finally, something we both agree on!