C# Nullable types

[Scott M.]

Again, you are getting phillisophical, rather than being pragmatic. I have
found that you will twist any argument in any way to prove your point.

Your agument could easily be analogous to the universe's size being
infinate. But does the universe have a particular value for its size? You
argue "Yes" - Its size is infinate, I argue "No" - there is no particular
size, which is expressed by saying infinate.

null is just a word - it's meaning is widely known to be "no value".

You can twist your words in any way that you like, but all you are doing is
making this way more complicated than it need be.

I know you know (despite your public stance here) that:

string x = null;

means that x should be initialized to no particular value and we tell the
compiler that by using the language specific word called "null". In VB,
we'd use the language specific keyword "Nothing".

But, I also know you know that:

string x;

is an unitialized variable. The compiler needs to make this distrinction
(between intentionally not specifying a value and perhaps not setting a
value by mistake), so we are given a keyword to state our intentions as the
developer. In other words, null is just a word we use to tell the compiler
what our intentions are. In C#, uninitialized variables are mostly not
allowed (because of the DAR), but we can pass compilation but stating our
intentions:

string x = null;

I am saying that I don't want x to have any value and I am "ok" with that.
The compiler then says, "ok, as long as you use x correctly and you know
what you are doing".

 

[Scott M.]

[...]
But it is not arbitrary, that is just plain wrong. See my above
comments. The meaning of "null" is not now, nor has it ever been
arbitrary, the "use" of nulls, yes, the "meaning", no.

You are using the word "meaning" in an arbitrarily different way than I
am. The "meaning" of "null" as I am describing it is EXACTLY THE SAME as
what the coder using the "null" value to indicate and has ABSOLUTELY
NOTHING to do with the way that the language defines or implements a
"null" value.

I don't think you know what the words arbitrary, meaning and use are because
your statements make absolutely no sense.

You have decided to play word games with the intent of the word "meaning",
but that doesn't make your point any more valid. Your criticism of the
original analogy is still unfounded. If someone wants to use "null" to
mean that the price of an object is unknown, there's absolutely nothing
wrong with that. The language allows it, normal human semantics allows
it, and you have no standing to tell someone they can't do it that way.

Um, ok. How about this then: The field of science called thermo-dynamics
deals with massive animal behaviors?

Do you accept that statement? I don't because it is wrong. And, I can tell
anyone that says it's right, that they are wrong. Saying that nulls =
unknowns is wrong, plain and simple. Saying that you can intialize a
variable as null for a value that will be determined later is a perfectly
good example of how and why one might initialize something as null, but it
is not a definition of null.

 

[Jon Skeet [C# MVP]]

Again, you are getting phillisophical, rather than being pragmatic. I have
found that you will twist any argument in any way to prove your point.

Well, I believe it's practical to think that a variable's value being
"no value" isn't terrible useful, compared with the definition of a
null value as per the spec, which is a special value indicating the
absence of an instance.

I know which definition I believe to be more consistent and less likely
to cause confusion. Apart from anything else, if everyone uses the
specified terminology rather than whatever terminology they happen to
like best, it's a lot easier to communicate.

Your agument could easily be analogous to the universe's size being
infinate. But does the universe have a particular value for its size? You
argue "Yes" - Its size is infinate, I argue "No" - there is no particular
size, which is expressed by saying infinate.

null is just a word - it's meaning is widely known to be "no value".

Its meaning is clearly defined in the C# spec - why not use that
definition? (In Java it's known as a value as well, by the way.)

Wikipedia agrees it's a value too:
http://en.wikipedia.org/wiki/Null_(computer)

<quote>
Null is a special value for a pointer (or other kind of object
reference) used to signify that the pointer intentionally does not have
a target.
</quote>

It's a special value, it's not *no* value.

You can twist your words in any way that you like, but all you are doing is
making this way more complicated than it need be.

I'm not twisting my words at all - I'm consistently using the same
terminology as the C# language specification. Surely that *defines* the
language, and should be seen as authoritative when talking about C#.

I know you know (despite your public stance here) that:

string x = null;

means that x should be initialized to no particular value and we tell the
compiler that by using the language specific word called "null".

No, it should be initialized to a very specific value - the null value.
It's defined as a value in the spec, it's quite easy to understand as
being a special value which refers to no object. It also makes it a lot
easier to understand when it comes to parameter passing. If I do:

string x = null;
SomeMethodCall();
SomeOtherMethodCall(null);

it's easy to say that the first method call is passing no values,
whereas the second method call is passing the null value. Using your
terminology, there's confusion as neither call is passing a value.

The language is so much easier to talk about when you consider null to
be a value. For instance, suppose we were to describe:

string x = SomeMethod();

I'd say that the variable x is assigned the value returned by
SomeMethodReturningNull. In your terminology where null *isn't* a
value, in order to be precise you'd have to describe what happened when
SomeMethod returns null, and what happened when SomeMethod returns a
non-null reference. You'd also have to describe the difference between
a method with no return value (i.e. one like void Foo()) and one which
actually has returned null (e.g. string Foo() { return null; } )

Do you not see how it's easier? What do you object to about the spec's
definition?

In VB, we'd use the language specific keyword "Nothing".

Yes, although of course that has a significantly wider meaning than
C#'s "null".

But, I also know you know that:

string x;

is an unitialized variable. The compiler needs to make this distrinction
(between intentionally not specifying a value and perhaps not setting a
value by mistake), so we are given a keyword to state our intentions as the
developer. In other words, null is just a word we use to tell the compiler
what our intentions are. In C#, uninitialized variables are mostly not
allowed (because of the DAR), but we can pass compilation but stating our
intentions:

string x = null;

I am saying that I don't want x to have any value and I am "ok" with that.
The compiler then says, "ok, as long as you use x correctly and you know
what you are doing".

Well, the spec doesn't say that's making x not have any value. It says
it's making x have the null value. Why do you want to go against the
spec?

 

[Rory Becker]

If you don't know the value, you don't know it is 27 so you'll have

NO! Stop right there. That is false! Just because I don't know the
value doesn't mean it can't have a value (like 27). Variables are
great examples of holders of potentially unknown values, that doesn't
make all variables null does it?

Sorry Scott. I don't think you understand what Patrice is trying to say.

(In fairness, I can't guarentee that I do either but according to my interpretation,
she's making sense. (erm that is a femanine name where you come from? Right
Patrice? I don't want to be insulting anyone This thread's heated enough
already. )

The way I see it, Patrice is trying to explain a valid use of null and therefore
a meaning which is appropriate for it.

When Patrice says "If you don't know the value, you don't know it is 27",
she means....

If you don't tell the computer that you have 27 apples then this fact is
unknown to the computer. This does not stop you from actually having the
27 apples though. As Patrice says, the best you can do is null (reasonably
taken in this circumstance to mean 'unknown')

You could decide to tell the computer that you have 27 apples or you could
not.

If you do not then the value would be null. (rather than 0 which most people
would agrees represented the "solid fact of there being no apples at all)

Therefore the null represents an as yet unknown or unspecified value.

To put it another way. If the computer tells you "it has 'null' apples",
what would any reasonable programmer taken that to mean. what would you take
it to mean.

Another good example could be a company with employees. you could

(Please excuse the VB here but I'm quicker using it and there are only reference
types in this example so initialising to null shouldn't be a contraversial
point here)

-------------------------------------------------------------
Class Company
Private mCompanyName as String
Public Employees as Collection(Of Employee)
Public Sub New(CompanyName as String)
mCompanyName = CompanyName
End Sub
End Class
-------------------------------------------------------------

After construction, an object of type company, would be a (very incomplete)
representation of a company in the real world.
In the real world, the company might have 5 or 100 Emplyees.

This information doesn't exist for the class yet and can it be reasonable
stated that it is unknown to the class.

However, we have not given an empty collection which might be interpreted
as inticating the "solid fact" that the company has 0 employees.

This is the use of null to mean that we do not know the correct value or
that it is as yet not available to us(perhaps because a lazy load has not
yet taken place or perhaps because the database record from which this data
might have been drawn did not specify for this particular company.

This is a common interpretation of the "meaning" null.

As someone indicated earlier in this thread, the meaning of "meaning" is
subject to interpretation (sorry for going a little bit meta).

We can interpret as I have above or we can interpret as if the use wanted
to know the strict definition of null.

I feel that Patrice has the correct interpretation of the original poster's
intention.

The original posters question is best answered (IMHO) by indicating how one
might usefully use a null.

The truth is that nobody should care whether a variable was assigned null
or whether it was null by virtue of not having ever been set.
This is because after either of these 2 events has occurred, noone can tell
which did cause it.

At this point "unassigned" becomes the same as "assigned null"

You can be as picky as you like and refer back to the specification as much
as you like.

Despite the fact that internally c#(and many other languages) represent null
as a special yet constant value (so that (null = null) is true...
.... Nobody cares what that value is (whether it is or is not a value). the
real crux of the matter is "what is it used for?", "how is it useful?" or
"what did the programmer of this code mean when (s)he used it?"

Ok that was a lot to type and I think I've repeated myself a lot. I have
not tried to insult anyone, so if you do feel as if I have then I'm sorry.

Either way.... Tag.... you're all IT

[BTW... "IT" is a special constant value (whose internal value we don't really
care about) which when applied to an individual or group, designates them
to be the person whose turn it is.]

Sorry couln't resist

 

[Scott M.]

Please fill in the blank with a specific value:

null = _____

Thank you.

 

[Scott M.]

By the way, Wikipedia says that null is a language-specific keyword, not a
value. Oh yes, Wikipedia also listed the comedian "Sinbad" as being dead
last month. He is very much alive. You would do well not to use Wikipedia
as a source of fact.

 

[Scott M.]

Rory,

I get what she is saying, but she is not getting my reply. As you state,
she is giving *uses* for null, not a definition of null. This has been my
whole point with her posts. I never said her example of the usage of null
was wrong, I said it was wrong to hold the usage up as a definition, that's
all.

NO! Stop right there. That is false! Just because I don't know the
value doesn't mean it can't have a value (like 27). Variables are
great examples of holders of potentially unknown values, that doesn't
make all variables null does it?

Sorry Scott. I don't think you understand what Patrice is trying to say.

(In fairness, I can't guarentee that I do either but according to my
interpretation, she's making sense. (erm that is a femanine name where you
come from? Right Patrice? I don't want to be insulting anyone This
thread's heated enough already. )

The way I see it, Patrice is trying to explain a valid use of null and
therefore a meaning which is appropriate for it.

When Patrice says "If you don't know the value, you don't know it is 27",
she means....

If you don't tell the computer that you have 27 apples then this fact is
unknown to the computer. This does not stop you from actually having the
27 apples though. As Patrice says, the best you can do is null (reasonably
taken in this circumstance to mean 'unknown')

You could decide to tell the computer that you have 27 apples or you could
not.

If you do not then the value would be null. (rather than 0 which most
people would agrees represented the "solid fact of there being no apples
at all)

Therefore the null represents an as yet unknown or unspecified value.

To put it another way. If the computer tells you "it has 'null' apples",
what would any reasonable programmer taken that to mean. what would you
take it to mean.

Another good example could be a company with employees. you could
(Please excuse the VB here but I'm quicker using it and there are only
reference types in this example so initialising to null shouldn't be a
contraversial point here)

-------------------------------------------------------------
Class Company
Private mCompanyName as String
Public Employees as Collection(Of Employee) Public Sub
New(CompanyName as String)
mCompanyName = CompanyName
End Sub End Class
-------------------------------------------------------------

After construction, an object of type company, would be a (very
incomplete) representation of a company in the real world.
In the real world, the company might have 5 or 100 Emplyees.

This information doesn't exist for the class yet and can it be reasonable
stated that it is unknown to the class.

However, we have not given an empty collection which might be interpreted
as inticating the "solid fact" that the company has 0 employees.

This is the use of null to mean that we do not know the correct value or
that it is as yet not available to us(perhaps because a lazy load has not
yet taken place or perhaps because the database record from which this
data might have been drawn did not specify for this particular company.

This is a common interpretation of the "meaning" null.

As someone indicated earlier in this thread, the meaning of "meaning" is
subject to interpretation (sorry for going a little bit meta).

We can interpret as I have above or we can interpret as if the use wanted
to know the strict definition of null.

I feel that Patrice has the correct interpretation of the original
poster's intention.

The original posters question is best answered (IMHO) by indicating how
one might usefully use a null.

The truth is that nobody should care whether a variable was assigned null
or whether it was null by virtue of not having ever been set.
This is because after either of these 2 events has occurred, noone can
tell which did cause it.

At this point "unassigned" becomes the same as "assigned null"

You can be as picky as you like and refer back to the specification as
much as you like.

Despite the fact that internally c#(and many other languages) represent
null as a special yet constant value (so that (null = null) is true...
... Nobody cares what that value is (whether it is or is not a value). the
real crux of the matter is "what is it used for?", "how is it useful?" or
"what did the programmer of this code mean when (s)he used it?"

Ok that was a lot to type and I think I've repeated myself a lot. I have
not tried to insult anyone, so if you do feel as if I have then I'm sorry.

Either way.... Tag.... you're all IT

[BTW... "IT" is a special constant value (whose internal value we don't
really care about) which when applied to an individual or group,
designates them to be the person whose turn it is.]

Sorry couln't resist

 

[Scott M.]

Sorry, I know how you'll parse this away from the main point, so let me be
more accurate:

Please fill in the blank with a specific value:

null = _____;

Please fill in the blank with a specific value:

null = _____

Thank you.

 

[Jon Skeet [C# MVP]]

Please fill in the blank with a specific value:

null = a special value which is compatible with all reference types
and indicates the absence of an instance

Thank you.

My pleasure.

 

[Jon Skeet [C# MVP]]

By the way, Wikipedia says that null is a language-specific keyword, not a
value. Oh yes, Wikipedia also listed the comedian "Sinbad" as being dead
last month. He is very much alive. You would do well not to use Wikipedia
as a source of fact.

While you continue to give vague "most people know" as your source?

Do you have anything against my *main* source, namely the C# language
specification which clearly indicates that null is a value?

 

[Scott M.]

While you continue to give vague "most people know" as your source?

Because I'm being pragmatic and you are (as I've often said about you)
splitting uneccesary hairs. This boils down to trivial "it depends on what
the meaning of "is" is stupidity.

Ask someone (a real world developer) what the value of null is and they will
respond exactly the way you just did to my other post, they'll say nothing.

Do you have anything against my *main* source, namely the C# language
specification which clearly indicates that null is a value?

I've already addressed my problem with calling null a value. Are you
seriously telling me that you have never run into documentation that is
inaccurate or uses a word incorrectly?

My problem is with your unrelenting parsing of words to get to a point
where the other person in the conversation is worn out by your semantics
that don't really pertain to the real world.

You've proven to me (again) that there is no such thing as a reasonable
conversation, so back on the filter list you go.

Bye Jon.

 

[Peter Duniho]

[...]

You are using the word "meaning" in an arbitrarily different way thanI
am. The "meaning" of "null" as I am describing it is EXACTLY THE SAME
as what the coder using the "null" value to indicate and has ABSOLUTELY
NOTHING to do with the way that the language defines or implements a
"null" value.

I don't think you know what the words arbitrary, meaning and use are
because your statements make absolutely no sense.

Perhaps you should get a dictionary then. I doubt anyone else has
anything trouble understanding what I wrote. (I did accidently leave out
a word, but that's not what you're complaining about and I doubt it
interferes with anyone actually reading the paragraph understanding it).

[...] Saying that nulls =
unknowns is wrong, plain and simple. Saying that you can intialize a
variable as null for a value that will be determined later is a perfectly
good example of how and why one might initialize something as null, but
it is not a definition of null.

You're the only one restricting this discussion to the "definition" of
null. It was clear from Patrice's post that he was providing an example
of how one would USE a nullable type or a null value. That is, the
"meaning" of a null value _in code_. He never wrote that he was
"defining" null, nor is there anything in his post that ought to suggest
that he was.

There is nothing wrong with his analogy, and your insistence on saying
that there is rather than simply apologizing for your misunderstanding of
his post adds absolutely zero to anyone's understanding of what a nullable
type is or how it might be used.

Pete

 

[Scott M.]

I don't think you know what the words arbitrary, meaning and use are

because your statements make absolutely no sense.

Perhaps you should get a dictionary then. I doubt anyone else has
anything trouble understanding what I wrote. (I did accidently leave out
a word, but that's not what you're complaining about and I doubt it
interferes with anyone actually reading the paragraph understanding it).

Now you are just being absurd. You really need me to tell you what
arbitrary means? Ok, take a look at this:

http://www.m-w.com/dictionary/arbitrary

I'll say it again and try to read and understand this before you just try to
dispute it:

"The meaning of "null" is not now, nor has it ever been
arbitrary, the "use" of nulls, yes, the "meaning", no."

Did you catch that last part? It goes to the point that you and Patrice are
talking about something different than what the OP asked and to which I have
been correcting you about. You are talking "usage" (context), I am talking
"meaning" (defintion). If yiou really are going to argue this, then you
need to buy one of those dictionaries when you are at their web site,
because now you just are making up definitions for English words as well as
programming terms.

[...] Saying that nulls =
unknowns is wrong, plain and simple. Saying that you can intialize a
variable as null for a value that will be determined later is a perfectly
good example of how and why one might initialize something as null, but
it is not a definition of null.

I'm sorry but there is nothing in that statement that is accurate or
informative. Let's see:

You're the only one restricting this discussion to the "definition" of
null.

Really? Hmmm, here's a direct quote from the OP: "what is actually a
null value". So, your first remark is incorrect and it's why I've been
correcting Patrice all along. The OP did not ask for potential usages of
null.

It was clear from Patrice's post that he was providing an example of how
one would USE a nullable type or a null value.

Yes, I agree and if you took the time to read the thread, you'd see that
this is EXACTLY what I have been saying all along. It does not, however,
answer the OP, hence my replies. So this statement is really irrelevant to
the topic.

That is, the "meaning" of a null value _in code_.

No, the meaning is the definition. To use your own words, a "USE" was
provided, not a meaning. In a spelling bee, the word to be spelled is used
in a sentence to give the contestant some context, it is not defined (with
one exception when a word has more than one homonym). This *may* be enough
to understand what the word *means* (its definition), but it also may not.
Usage != definition.

He never wrote that he was "defining" null, nor is there anything
in his post that ought to suggest that he was.

What thread have you been reading? Since the very first time I pointed out
that he was providing a usage, rather than a definition, he's countered that
his explantion is the correct way to answer the OP (which, in case you
forgot was "what is actually a null value").

There is nothing wrong with his analogy, and your insistence on saying
that there is rather than simply apologizing for your misunderstanding of
his post adds absolutely zero to anyone's understanding of what a nullable
type is or how it might be used.

What part of null means "no value" did you not get? The OP didn't ask for
how a nullable type might be used. Are you reading your own bull as you
write it?

If you can't see that I have understood his posts from the go, and simply
been trying to tell him what you, yourself just pointed out, then I'm afraid
it is you that has a misunderstanding of this thread. It's obvious you've
jumped in here in the middle and not read the whole thread. I won't hold my
breath though for your apology.

 

[Jon Skeet [C# MVP]]

Because I'm being pragmatic and you are (as I've often said about you)
splitting uneccesary hairs. This boils down to trivial "it depends on what
the meaning of "is" is stupidity.

No - the difference between an unassigned variable and one with a value
of null is *not* trivial. It's important to understand, *and* it makes
talking about the rest of the lanugage simpler.

Ask someone (a real world developer) what the value of null is and they will
respond exactly the way you just did to my other post, they'll say nothing.

I would hope many would say that it's a reference value which doesn't
reference any object.

I've already addressed my problem with calling null a value. Are you
seriously telling me that you have never run into documentation that is
inaccurate or uses a word incorrectly?

So you're claiming that the C# spec, the Java spec and the C++ spec are
all "wrong" (despite the fact that they get to define how terminology
is used for their own languages), but *your* definition, which you
haven't provided any references for, is the absolute truth.

My problem is with your unrelenting parsing of words to get to a point
where the other person in the conversation is worn out by your semantics
that don't really pertain to the real world.

You've proven to me (again) that there is no such thing as a reasonable
conversation, so back on the filter list you go.

My "unrelenting parsing" is merely trying to stick to the spec. I'm not
unhappy that you're filtering me out, however - apart from anything
else, the ad hominem attacks get somewhat wearing.

 

[Patrice]

Well no. This is actually the same as Patrick here in France. The feminim
form for us is Patricia.

NO! Stop right there. That is false! Just because I don't know the
value doesn't mean it can't have a value (like 27). Variables are
great examples of holders of potentially unknown values, that doesn't
make all variables null does it?

Sorry Scott. I don't think you understand what Patrice is trying to say.

(In fairness, I can't guarentee that I do either but according to my
interpretation, she's making sense. (erm that is a femanine name where you
come from? Right Patrice? I don't want to be insulting anyone This
thread's heated enough already. )

The way I see it, Patrice is trying to explain a valid use of null and
therefore a meaning which is appropriate for it.

When Patrice says "If you don't know the value, you don't know it is 27",
she means....

If you don't tell the computer that you have 27 apples then this fact is
unknown to the computer. This does not stop you from actually having the
27 apples though. As Patrice says, the best you can do is null (reasonably
taken in this circumstance to mean 'unknown')

You could decide to tell the computer that you have 27 apples or you could
not.

If you do not then the value would be null. (rather than 0 which most
people would agrees represented the "solid fact of there being no apples
at all)

Therefore the null represents an as yet unknown or unspecified value.

To put it another way. If the computer tells you "it has 'null' apples",
what would any reasonable programmer taken that to mean. what would you
take it to mean.

Another good example could be a company with employees. you could
(Please excuse the VB here but I'm quicker using it and there are only
reference types in this example so initialising to null shouldn't be a
contraversial point here)

-------------------------------------------------------------
Class Company
Private mCompanyName as String
Public Employees as Collection(Of Employee) Public Sub
New(CompanyName as String)
mCompanyName = CompanyName
End Sub End Class
-------------------------------------------------------------

After construction, an object of type company, would be a (very
incomplete) representation of a company in the real world.
In the real world, the company might have 5 or 100 Emplyees.

This information doesn't exist for the class yet and can it be reasonable
stated that it is unknown to the class.

However, we have not given an empty collection which might be interpreted
as inticating the "solid fact" that the company has 0 employees.

This is the use of null to mean that we do not know the correct value or
that it is as yet not available to us(perhaps because a lazy load has not
yet taken place or perhaps because the database record from which this
data might have been drawn did not specify for this particular company.

This is a common interpretation of the "meaning" null.

As someone indicated earlier in this thread, the meaning of "meaning" is
subject to interpretation (sorry for going a little bit meta).

We can interpret as I have above or we can interpret as if the use wanted
to know the strict definition of null.

I feel that Patrice has the correct interpretation of the original
poster's intention.

The original posters question is best answered (IMHO) by indicating how
one might usefully use a null.

The truth is that nobody should care whether a variable was assigned null
or whether it was null by virtue of not having ever been set.
This is because after either of these 2 events has occurred, noone can
tell which did cause it.

At this point "unassigned" becomes the same as "assigned null"

You can be as picky as you like and refer back to the specification as
much as you like.

Despite the fact that internally c#(and many other languages) represent
null as a special yet constant value (so that (null = null) is true...
... Nobody cares what that value is (whether it is or is not a value). the
real crux of the matter is "what is it used for?", "how is it useful?" or
"what did the programmer of this code mean when (s)he used it?"

Ok that was a lot to type and I think I've repeated myself a lot. I have
not tried to insult anyone, so if you do feel as if I have then I'm sorry.

Either way.... Tag.... you're all IT

[BTW... "IT" is a special constant value (whose internal value we don't
really care about) which when applied to an individual or group,
designates them to be the person whose turn it is.]

Sorry couln't resist

 

[Patrice]

Got it now but I give up anyway to understand what you thought that the OP
just wanted a definition without being interested in how he could use it...

Bye.

Rory,

I get what she is saying, but she is not getting my reply. As you state,
she is giving *uses* for null, not a definition of null. This has been my
whole point with her posts. I never said her example of the usage of null
was wrong, I said it was wrong to hold the usage up as a definition,
that's all.

If you don't know the value, you don't know it is 27 so you'll have
a "null" value anyway as you can't do better....

NO! Stop right there. That is false! Just because I don't know the
value doesn't mean it can't have a value (like 27). Variables are
great examples of holders of potentially unknown values, that doesn't
make all variables null does it?

Sorry Scott. I don't think you understand what Patrice is trying to say.

(In fairness, I can't guarentee that I do either but according to my
interpretation, she's making sense. (erm that is a femanine name where
you come from? Right Patrice? I don't want to be insulting anyone This
thread's heated enough already. )

The way I see it, Patrice is trying to explain a valid use of null and
therefore a meaning which is appropriate for it.

When Patrice says "If you don't know the value, you don't know it is
27", she means....

If you don't tell the computer that you have 27 apples then this fact is
unknown to the computer. This does not stop you from actually having the
27 apples though. As Patrice says, the best you can do is null
(reasonably taken in this circumstance to mean 'unknown')

You could decide to tell the computer that you have 27 apples or you
could not.

If you do not then the value would be null. (rather than 0 which most
people would agrees represented the "solid fact of there being no apples
at all)

Therefore the null represents an as yet unknown or unspecified value.

To put it another way. If the computer tells you "it has 'null' apples",
what would any reasonable programmer taken that to mean. what would you
take it to mean.

Another good example could be a company with employees. you could
(Please excuse the VB here but I'm quicker using it and there are only
reference types in this example so initialising to null shouldn't be a
contraversial point here)

-------------------------------------------------------------
Class Company
Private mCompanyName as String
Public Employees as Collection(Of Employee) Public Sub
New(CompanyName as String)
mCompanyName = CompanyName
End Sub End Class
-------------------------------------------------------------

After construction, an object of type company, would be a (very
incomplete) representation of a company in the real world.
In the real world, the company might have 5 or 100 Emplyees.

This information doesn't exist for the class yet and can it be reasonable
stated that it is unknown to the class.

However, we have not given an empty collection which might be interpreted
as inticating the "solid fact" that the company has 0 employees.

This is the use of null to mean that we do not know the correct value or
that it is as yet not available to us(perhaps because a lazy load has not
yet taken place or perhaps because the database record from which this
data might have been drawn did not specify for this particular company.

This is a common interpretation of the "meaning" null.

As someone indicated earlier in this thread, the meaning of "meaning" is
subject to interpretation (sorry for going a little bit meta).

We can interpret as I have above or we can interpret as if the use wanted
to know the strict definition of null.

I feel that Patrice has the correct interpretation of the original
poster's intention.

The original posters question is best answered (IMHO) by indicating how
one might usefully use a null.

The truth is that nobody should care whether a variable was assigned null
or whether it was null by virtue of not having ever been set.
This is because after either of these 2 events has occurred, noone can
tell which did cause it.

At this point "unassigned" becomes the same as "assigned null"

You can be as picky as you like and refer back to the specification as
much as you like.

Despite the fact that internally c#(and many other languages) represent
null as a special yet constant value (so that (null = null) is true...
... Nobody cares what that value is (whether it is or is not a value).
the real crux of the matter is "what is it used for?", "how is it
useful?" or "what did the programmer of this code mean when (s)he used
it?"

Ok that was a lot to type and I think I've repeated myself a lot. I have
not tried to insult anyone, so if you do feel as if I have then I'm
sorry.

Either way.... Tag.... you're all IT

[BTW... "IT" is a special constant value (whose internal value we don't
really care about) which when applied to an individual or group,
designates them to be the person whose turn it is.]

Sorry couln't resist

 

[Scott M.]

Because your first (and all the other) post(s) were only providing useage
scenarios. You never provided a definition. And (as I stated way back),
the analogy you used, I feel was incorrect and misleading.

Got it now but I give up anyway to understand what you thought that the OP
just wanted a definition without being interested in how he could use
it...

Bye.

Rory,

I get what she is saying, but she is not getting my reply. As you state,
she is giving *uses* for null, not a definition of null. This has been
my whole point with her posts. I never said her example of the usage of
null was wrong, I said it was wrong to hold the usage up as a definition,
that's all.

If you don't know the value, you don't know it is 27 so you'll have
a "null" value anyway as you can't do better....

NO! Stop right there. That is false! Just because I don't know the
value doesn't mean it can't have a value (like 27). Variables are
great examples of holders of potentially unknown values, that doesn't
make all variables null does it?

Sorry Scott. I don't think you understand what Patrice is trying to say.

(In fairness, I can't guarentee that I do either but according to my
interpretation, she's making sense. (erm that is a femanine name where
you come from? Right Patrice? I don't want to be insulting anyone
This thread's heated enough already. )

The way I see it, Patrice is trying to explain a valid use of null and
therefore a meaning which is appropriate for it.

When Patrice says "If you don't know the value, you don't know it is
27", she means....

If you don't tell the computer that you have 27 apples then this fact is
unknown to the computer. This does not stop you from actually having the
27 apples though. As Patrice says, the best you can do is null
(reasonably taken in this circumstance to mean 'unknown')

You could decide to tell the computer that you have 27 apples or you
could not.

If you do not then the value would be null. (rather than 0 which most
people would agrees represented the "solid fact of there being no apples
at all)

Therefore the null represents an as yet unknown or unspecified value.

To put it another way. If the computer tells you "it has 'null' apples",
what would any reasonable programmer taken that to mean. what would you
take it to mean.

Another good example could be a company with employees. you could
(Please excuse the VB here but I'm quicker using it and there are only
reference types in this example so initialising to null shouldn't be a
contraversial point here)

-------------------------------------------------------------
Class Company
Private mCompanyName as String
Public Employees as Collection(Of Employee) Public Sub
New(CompanyName as String)
mCompanyName = CompanyName
End Sub End Class
-------------------------------------------------------------

After construction, an object of type company, would be a (very
incomplete) representation of a company in the real world.
In the real world, the company might have 5 or 100 Emplyees.

This information doesn't exist for the class yet and can it be
reasonable stated that it is unknown to the class.

However, we have not given an empty collection which might be
interpreted as inticating the "solid fact" that the company has 0
employees.

This is the use of null to mean that we do not know the correct value or
that it is as yet not available to us(perhaps because a lazy load has
not yet taken place or perhaps because the database record from which
this data might have been drawn did not specify for this particular
company.

This is a common interpretation of the "meaning" null.

As someone indicated earlier in this thread, the meaning of "meaning" is
subject to interpretation (sorry for going a little bit meta).

We can interpret as I have above or we can interpret as if the use
wanted to know the strict definition of null.

I feel that Patrice has the correct interpretation of the original
poster's intention.

The original posters question is best answered (IMHO) by indicating how
one might usefully use a null.

The truth is that nobody should care whether a variable was assigned
null or whether it was null by virtue of not having ever been set.
This is because after either of these 2 events has occurred, noone can
tell which did cause it.

At this point "unassigned" becomes the same as "assigned null"

You can be as picky as you like and refer back to the specification as
much as you like.

Despite the fact that internally c#(and many other languages) represent
null as a special yet constant value (so that (null = null) is true...
... Nobody cares what that value is (whether it is or is not a value).
the real crux of the matter is "what is it used for?", "how is it
useful?" or "what did the programmer of this code mean when (s)he used
it?"

Ok that was a lot to type and I think I've repeated myself a lot. I have
not tried to insult anyone, so if you do feel as if I have then I'm
sorry.

Either way.... Tag.... you're all IT

[BTW... "IT" is a special constant value (whose internal value we don't
really care about) which when applied to an individual or group,
designates them to be the person whose turn it is.]

Sorry couln't resist

 

[Scott M.]

....And, only providing useage (context) is not always sufficient for a clear
understanding of meaning (definition).

So, since you only provided useage, and I believe inaccurate useage at that
(database useage of null [which was, in itself misleading], rather than .NET
useage of null), there was no good description of C#'s null ever given by
you.

Because your first (and all the other) post(s) were only providing useage
scenarios. You never provided a definition. And (as I stated way back),
the analogy you used, I feel was incorrect and misleading.

Got it now but I give up anyway to understand what you thought that the
OP just wanted a definition without being interested in how he could use
it...

Bye.

Rory,

I get what she is saying, but she is not getting my reply. As you
state, she is giving *uses* for null, not a definition of null. This
has been my whole point with her posts. I never said her example of the
usage of null was wrong, I said it was wrong to hold the usage up as a
definition, that's all.


If you don't know the value, you don't know it is 27 so you'll have
a "null" value anyway as you can't do better....

NO! Stop right there. That is false! Just because I don't know the
value doesn't mean it can't have a value (like 27). Variables are
great examples of holders of potentially unknown values, that doesn't
make all variables null does it?

Sorry Scott. I don't think you understand what Patrice is trying to
say.

(In fairness, I can't guarentee that I do either but according to my
interpretation, she's making sense. (erm that is a femanine name where
you come from? Right Patrice? I don't want to be insulting anyone
This thread's heated enough already. )

The way I see it, Patrice is trying to explain a valid use of null and
therefore a meaning which is appropriate for it.

When Patrice says "If you don't know the value, you don't know it is
27", she means....

If you don't tell the computer that you have 27 apples then this fact
is unknown to the computer. This does not stop you from actually having
the 27 apples though. As Patrice says, the best you can do is null
(reasonably taken in this circumstance to mean 'unknown')

You could decide to tell the computer that you have 27 apples or you
could not.

If you do not then the value would be null. (rather than 0 which most
people would agrees represented the "solid fact of there being no
apples at all)

Therefore the null represents an as yet unknown or unspecified value.

To put it another way. If the computer tells you "it has 'null'
apples", what would any reasonable programmer taken that to mean. what
would you take it to mean.

Another good example could be a company with employees. you could
(Please excuse the VB here but I'm quicker using it and there are only
reference types in this example so initialising to null shouldn't be a
contraversial point here)

-------------------------------------------------------------
Class Company
Private mCompanyName as String
Public Employees as Collection(Of Employee) Public Sub
New(CompanyName as String)
mCompanyName = CompanyName
End Sub End Class
-------------------------------------------------------------

After construction, an object of type company, would be a (very
incomplete) representation of a company in the real world.
In the real world, the company might have 5 or 100 Emplyees.

This information doesn't exist for the class yet and can it be
reasonable stated that it is unknown to the class.

However, we have not given an empty collection which might be
interpreted as inticating the "solid fact" that the company has 0
employees.

This is the use of null to mean that we do not know the correct value
or that it is as yet not available to us(perhaps because a lazy load
has not yet taken place or perhaps because the database record from
which this data might have been drawn did not specify for this
particular company.

This is a common interpretation of the "meaning" null.

As someone indicated earlier in this thread, the meaning of "meaning"
is subject to interpretation (sorry for going a little bit meta).

We can interpret as I have above or we can interpret as if the use
wanted to know the strict definition of null.

I feel that Patrice has the correct interpretation of the original
poster's intention.

The original posters question is best answered (IMHO) by indicating how
one might usefully use a null.

The truth is that nobody should care whether a variable was assigned
null or whether it was null by virtue of not having ever been set.
This is because after either of these 2 events has occurred, noone can
tell which did cause it.

At this point "unassigned" becomes the same as "assigned null"

You can be as picky as you like and refer back to the specification as
much as you like.

Despite the fact that internally c#(and many other languages) represent
null as a special yet constant value (so that (null = null) is true...
... Nobody cares what that value is (whether it is or is not a value).
the real crux of the matter is "what is it used for?", "how is it
useful?" or "what did the programmer of this code mean when (s)he used
it?"

Ok that was a lot to type and I think I've repeated myself a lot. I
have not tried to insult anyone, so if you do feel as if I have then
I'm sorry.

Either way.... Tag.... you're all IT

[BTW... "IT" is a special constant value (whose internal value we don't
really care about) which when applied to an individual or group,
designates them to be the person whose turn it is.]

Sorry couln't resist