Home All Groups Group Topic Archive Search About
Author
4 Apr 2007 10:38 AM
AVL
hi,
i'm a new bie to c#.net 2.0....
i've come across a new feature by name nullable types...need some info on it

what is actually a null value...
what exactly is advantage we get by specifying a value type as a null value...

please clarify
Author
4 Apr 2007 11:12 AM
Patrice
For example for a price it would allow to distingusih between something that
is free (0) and something for which don't know the price (null).

It's likely you'll mostly use this for dates (if the vetn occured the date
will be filled, if the event didnt' occured date, the date will be null).

---
Patrice

"AVL" <A**@discussions.microsoft.com> a écrit dans le message de news:
49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
Show quoteHide quote
> hi,
> i'm a new bie to c#.net 2.0....
> i've come across a new feature by name nullable types...need some info on
> it
>
> what is actually a null value...
> what exactly is advantage we get by specifying a value type as a null
> value...
>
> please clarify
Are all your drivers up to date? click for free checkup

Author
4 Apr 2007 5:08 PM
Scott M.
I would have to disagree with your analogy.

If someting is free, it still has a value of zero dollars (as you say), but
if we don't know the price, that doesn't make the price null, it just makes
the price unkown.

null is simply a keyword that indicates that the item in question does not
have a relationship to any data at all.

A = 0    <-- A has a value of zero
A = " "   <-- A has a value of the space char
A = ""    <-- A has a null value (no data at all)

The benefit of null values is primarially when using databases, since most
databases have tables where not all fields are required to have a value
(like a middle name or apartment number or name suffix, such as Sr. or Jr.).
Since it is possible that a field may be null, we need a way of checking it
as such or passing null values into it.

-Scott

Show quoteHide quote
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl...
> For example for a price it would allow to distingusih between something
> that is free (0) and something for which don't know the price (null).
>
> It's likely you'll mostly use this for dates (if the vetn occured the date
> will be filled, if the event didnt' occured date, the date will be null).
>
> ---
> Patrice
>
> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news:
> 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
>> hi,
>> i'm a new bie to c#.net 2.0....
>> i've come across a new feature by name nullable types...need some info on
>> it
>>
>> what is actually a null value...
>> what exactly is advantage we get by specifying a value type as a null
>> value...
>>
>> please clarify
>
>
Author
4 Apr 2007 5:15 PM
Jon Skeet [C# MVP]
Scott M. <s-mar@nospam.nospam> wrote:
> I would have to disagree with your analogy.
>
> If someting is free, it still has a value of zero dollars (as you say), but
> if we don't know the price, that doesn't make the price null, it just makes
> the price unkown.
>
> null is simply a keyword that indicates that the item in question does not
> have a relationship to any data at all.

That much I'd agree with.

> A = 0    <-- A has a value of zero
> A = " "   <-- A has a value of the space char
> A = ""    <-- A has a null value (no data at all)

That particular example is a bit confusing, as the string literal ""
and null are very different. One is a reference to a 0-length string,
the other is a reference to no object at all.

So I'd say that "" has data - it has the data that it's an empty
string.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
4 Apr 2007 6:10 PM
Patrice
Not sure what you meant. How would you mark that the price is unknown if not
using a "nullable" type representing a null value ? As a side note, an empty
string is not a "null" string (in the first case we known that the value is
a zero length string, in the other case we don't know what the value is).

IMO one of the problem in discussing is that null has multiple acceptances.
In the context of a nullable type this is the same than the "NULL" (Il'l use
uppercase for this meaning) marker used in most DB, not the "null"
refererence as usual in C# (likely why MS used HasValue for what is called
"nullable" types toa void the ambiguity). VB.NET uses the Nothing keyword.

Finally I see sometimes what is IMO an abusive use of NULL. If you know that
you have no name suffix, you don't have to use a NULL value but an empty
string will do. You have to use a NULLable column if you want to distinguish
if the value is an empty string or if it has no meaning (i.e. not "known",
"applicable" or whatever semantic you attribute to the NULL value).
---
Patrice


"Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
%23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl...
Show quoteHide quote
>I would have to disagree with your analogy.
>
> If someting is free, it still has a value of zero dollars (as you say),
> but if we don't know the price, that doesn't make the price null, it just
> makes the price unkown.
>
> null is simply a keyword that indicates that the item in question does not
> have a relationship to any data at all.
>
> A = 0    <-- A has a value of zero
> A = " "   <-- A has a value of the space char
> A = ""    <-- A has a null value (no data at all)
>
> The benefit of null values is primarially when using databases, since most
> databases have tables where not all fields are required to have a value
> (like a middle name or apartment number or name suffix, such as Sr. or
> Jr.). Since it is possible that a field may be null, we need a way of
> checking it as such or passing null values into it.
>
> -Scott
>
> "Patrice" <http://www.chez.com/scribe/> wrote in message
> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl...
>> For example for a price it would allow to distingusih between something
>> that is free (0) and something for which don't know the price (null).
>>
>> It's likely you'll mostly use this for dates (if the vetn occured the
>> date will be filled, if the event didnt' occured date, the date will be
>> null).
>>
>> ---
>> Patrice
>>
>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news:
>> 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
>>> hi,
>>> i'm a new bie to c#.net 2.0....
>>> i've come across a new feature by name nullable types...need some info
>>> on it
>>>
>>> what is actually a null value...
>>> what exactly is advantage we get by specifying a value type as a null
>>> value...
>>>
>>> please clarify
>>
>>
>
>
Author
4 Apr 2007 7:20 PM
Scott M.
Something having an unknown value is not, in any way, related to a
dissussion of null.  The very word you use "unkown" implies that there is,
in fact, something to "know".  A null value indicates the exact opposite of
that, that there is no value at all.  That's why I said that your alaogy was
not a good one.

When I run into situations where a value is unknown to me, I set up a
variable to capture that value.  After doing that, I can then look to see if
the varialbe is null, seven, "green" or anything else.  The fact that I
didn't know the value of the variable does not imply null.

You seem to be discussing what a "nullable type" is, rather than the meaning
of "null".




Show quoteHide quote
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl...
> Not sure what you meant. How would you mark that the price is unknown if
> not using a "nullable" type representing a null value ? As a side note, an
> empty string is not a "null" string (in the first case we known that the
> value is a zero length string, in the other case we don't know what the
> value is).
>
> IMO one of the problem in discussing is that null has multiple
> acceptances. In the context of a nullable type this is the same than the
> "NULL" (Il'l use uppercase for this meaning) marker used in most DB, not
> the "null" refererence as usual in C# (likely why MS used HasValue for
> what is called "nullable" types toa void the ambiguity). VB.NET uses the
> Nothing keyword.
>
> Finally I see sometimes what is IMO an abusive use of NULL. If you know
> that you have no name suffix, you don't have to use a NULL value but an
> empty string will do. You have to use a NULLable column if you want to
> distinguish if the value is an empty string or if it has no meaning (i.e.
> not "known", "applicable" or whatever semantic you attribute to the NULL
> value).
> ---
> Patrice
>
>
> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl...
>>I would have to disagree with your analogy.
>>
>> If someting is free, it still has a value of zero dollars (as you say),
>> but if we don't know the price, that doesn't make the price null, it just
>> makes the price unkown.
>>
>> null is simply a keyword that indicates that the item in question does
>> not have a relationship to any data at all.
>>
>> A = 0    <-- A has a value of zero
>> A = " "   <-- A has a value of the space char
>> A = ""    <-- A has a null value (no data at all)
>>
>> The benefit of null values is primarially when using databases, since
>> most databases have tables where not all fields are required to have a
>> value (like a middle name or apartment number or name suffix, such as Sr.
>> or Jr.). Since it is possible that a field may be null, we need a way of
>> checking it as such or passing null values into it.
>>
>> -Scott
>>
>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl...
>>> For example for a price it would allow to distingusih between something
>>> that is free (0) and something for which don't know the price (null).
>>>
>>> It's likely you'll mostly use this for dates (if the vetn occured the
>>> date will be filled, if the event didnt' occured date, the date will be
>>> null).
>>>
>>> ---
>>> Patrice
>>>
>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news:
>>> 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
>>>> hi,
>>>> i'm a new bie to c#.net 2.0....
>>>> i've come across a new feature by name nullable types...need some info
>>>> on it
>>>>
>>>> what is actually a null value...
>>>> what exactly is advantage we get by specifying a value type as a null
>>>> value...
>>>>
>>>> please clarify
>>>
>>>
>>
>>
>
>
Author
5 Apr 2007 7:57 AM
Patrice
OK I perhaps see a bit better your semantic point. AFAIK some additional
"markers" were suggested in SQL standards to better define various meanings
of "undefined", "unknown"," not applicable" or several other semantics given
to NULL values but never made into products...

I perhaps miss also some nuances as English is not my native language but
hopefull the overall picture should be clear enough for the OP.


"Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl...
Show quoteHide quote
> Something having an unknown value is not, in any way, related to a
> dissussion of null.  The very word you use "unkown" implies that there is,
> in fact, something to "know".  A null value indicates the exact opposite
> of that, that there is no value at all.  That's why I said that your
> alaogy was not a good one.
>
> When I run into situations where a value is unknown to me, I set up a
> variable to capture that value.  After doing that, I can then look to see
> if the varialbe is null, seven, "green" or anything else.  The fact that I
> didn't know the value of the variable does not imply null.
>
> You seem to be discussing what a "nullable type" is, rather than the
> meaning of "null".
>
>
>
>
> "Patrice" <http://www.chez.com/scribe/> wrote in message
> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl...
>> Not sure what you meant. How would you mark that the price is unknown if
>> not using a "nullable" type representing a null value ? As a side note,
>> an empty string is not a "null" string (in the first case we known that
>> the value is a zero length string, in the other case we don't know what
>> the value is).
>>
>> IMO one of the problem in discussing is that null has multiple
>> acceptances. In the context of a nullable type this is the same than the
>> "NULL" (Il'l use uppercase for this meaning) marker used in most DB, not
>> the "null" refererence as usual in C# (likely why MS used HasValue for
>> what is called "nullable" types toa void the ambiguity). VB.NET uses the
>> Nothing keyword.
>>
>> Finally I see sometimes what is IMO an abusive use of NULL. If you know
>> that you have no name suffix, you don't have to use a NULL value but an
>> empty string will do. You have to use a NULLable column if you want to
>> distinguish if the value is an empty string or if it has no meaning (i.e.
>> not "known", "applicable" or whatever semantic you attribute to the NULL
>> value).
>> ---
>> Patrice
>>
>>
>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl...
>>>I would have to disagree with your analogy.
>>>
>>> If someting is free, it still has a value of zero dollars (as you say),
>>> but if we don't know the price, that doesn't make the price null, it
>>> just makes the price unkown.
>>>
>>> null is simply a keyword that indicates that the item in question does
>>> not have a relationship to any data at all.
>>>
>>> A = 0    <-- A has a value of zero
>>> A = " "   <-- A has a value of the space char
>>> A = ""    <-- A has a null value (no data at all)
>>>
>>> The benefit of null values is primarially when using databases, since
>>> most databases have tables where not all fields are required to have a
>>> value (like a middle name or apartment number or name suffix, such as
>>> Sr. or Jr.). Since it is possible that a field may be null, we need a
>>> way of checking it as such or passing null values into it.
>>>
>>> -Scott
>>>
>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl...
>>>> For example for a price it would allow to distingusih between something
>>>> that is free (0) and something for which don't know the price (null).
>>>>
>>>> It's likely you'll mostly use this for dates (if the vetn occured the
>>>> date will be filled, if the event didnt' occured date, the date will be
>>>> null).
>>>>
>>>> ---
>>>> Patrice
>>>>
>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news:
>>>> 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
>>>>> hi,
>>>>> i'm a new bie to c#.net 2.0....
>>>>> i've come across a new feature by name nullable types...need some info
>>>>> on it
>>>>>
>>>>> what is actually a null value...
>>>>> what exactly is advantage we get by specifying a value type as a null
>>>>> value...
>>>>>
>>>>> please clarify
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Author
5 Apr 2007 1:19 PM
Scott M.
Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," not
applicable" have never been identified with "null" in SQL or anywhere else.
When I mark a filed in SQL as "nullable", I am not doing it because I don't
know what value the user may want to put into the field.  On the contrary, I
do it because I'm letting the user not put any value at all into the field.

Again "undefined", "unknown"," not applicable" does not equal "null".  I
think this is super-important to be clear on, because "null" has a special
purpose and meaning and the minute you try to attach a meaning that is
something similiar, but not the same, to it, you confuse the issue and make
it more complicated than it need be.


Show quoteHide quote
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl...
> OK I perhaps see a bit better your semantic point. AFAIK some additional
> "markers" were suggested in SQL standards to better define various
> meanings of "undefined", "unknown"," not applicable" or several other
> semantics given to NULL values but never made into products...
>
> I perhaps miss also some nuances as English is not my native language but
> hopefull the overall picture should be clear enough for the OP.
>
>
> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
> ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl...
>> Something having an unknown value is not, in any way, related to a
>> dissussion of null.  The very word you use "unkown" implies that there
>> is, in fact, something to "know".  A null value indicates the exact
>> opposite of that, that there is no value at all.  That's why I said that
>> your alaogy was not a good one.
>>
>> When I run into situations where a value is unknown to me, I set up a
>> variable to capture that value.  After doing that, I can then look to see
>> if the varialbe is null, seven, "green" or anything else.  The fact that
>> I didn't know the value of the variable does not imply null.
>>
>> You seem to be discussing what a "nullable type" is, rather than the
>> meaning of "null".
>>
>>
>>
>>
>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl...
>>> Not sure what you meant. How would you mark that the price is unknown if
>>> not using a "nullable" type representing a null value ? As a side note,
>>> an empty string is not a "null" string (in the first case we known that
>>> the value is a zero length string, in the other case we don't know what
>>> the value is).
>>>
>>> IMO one of the problem in discussing is that null has multiple
>>> acceptances. In the context of a nullable type this is the same than the
>>> "NULL" (Il'l use uppercase for this meaning) marker used in most DB, not
>>> the "null" refererence as usual in C# (likely why MS used HasValue for
>>> what is called "nullable" types toa void the ambiguity). VB.NET uses the
>>> Nothing keyword.
>>>
>>> Finally I see sometimes what is IMO an abusive use of NULL. If you know
>>> that you have no name suffix, you don't have to use a NULL value but an
>>> empty string will do. You have to use a NULLable column if you want to
>>> distinguish if the value is an empty string or if it has no meaning
>>> (i.e. not "known", "applicable" or whatever semantic you attribute to
>>> the NULL value).
>>> ---
>>> Patrice
>>>
>>>
>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl...
>>>>I would have to disagree with your analogy.
>>>>
>>>> If someting is free, it still has a value of zero dollars (as you say),
>>>> but if we don't know the price, that doesn't make the price null, it
>>>> just makes the price unkown.
>>>>
>>>> null is simply a keyword that indicates that the item in question does
>>>> not have a relationship to any data at all.
>>>>
>>>> A = 0    <-- A has a value of zero
>>>> A = " "   <-- A has a value of the space char
>>>> A = ""    <-- A has a null value (no data at all)
>>>>
>>>> The benefit of null values is primarially when using databases, since
>>>> most databases have tables where not all fields are required to have a
>>>> value (like a middle name or apartment number or name suffix, such as
>>>> Sr. or Jr.). Since it is possible that a field may be null, we need a
>>>> way of checking it as such or passing null values into it.
>>>>
>>>> -Scott
>>>>
>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl...
>>>>> For example for a price it would allow to distingusih between
>>>>> something that is free (0) and something for which don't know the
>>>>> price (null).
>>>>>
>>>>> It's likely you'll mostly use this for dates (if the vetn occured the
>>>>> date will be filled, if the event didnt' occured date, the date will
>>>>> be null).
>>>>>
>>>>> ---
>>>>> Patrice
>>>>>
>>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de news:
>>>>> 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
>>>>>> hi,
>>>>>> i'm a new bie to c#.net 2.0....
>>>>>> i've come across a new feature by name nullable types...need some
>>>>>> info on it
>>>>>>
>>>>>> what is actually a null value...
>>>>>> what exactly is advantage we get by specifying a value type as a null
>>>>>> value...
>>>>>>
>>>>>> please clarify
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Author
5 Apr 2007 2:33 PM
Patrice
I'm not using null when "I don't know what value the user may want to input"
(actually I never know what value the user will enter, not sure what you
meant).

Also I don't use NULL when "I'm letting the user not put any value at all
into the field" which is IMO bad form at least to do systematically. I'll
use an empty string or 0 as a default value if it makes senses.

I will use this for example for the actual start date of something that not
started yet. In  this case you can't provide any value. IMO this is a more
convincing sample than Appartement number and the like where in a real world
scenario you never want to distinguish between a value that can't be
provided for some reason (null) and the fact that the apartment number is
just an empty string because you *know* this is an empty string, not because
you are unable to provide this value.

This is perhaps why I tried at first to explain what's behind null. I felt
that using simply the word "null" was perhaps not sufficient as it is IMO
sometimes misused.

---
Patrice

"Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
OTi6AT4dHHA.1***@TK2MSFTNGP04.phx.gbl...
Show quoteHide quote
> Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," not
> applicable" have never been identified with "null" in SQL or anywhere
> else. When I mark a filed in SQL as "nullable", I am not doing it because
> I don't know what value the user may want to put into the field.  On the
> contrary, I do it because I'm letting the user not put any value at all
> into the field.
>
> Again "undefined", "unknown"," not applicable" does not equal "null".  I
> think this is super-important to be clear on, because "null" has a special
> purpose and meaning and the minute you try to attach a meaning that is
> something similiar, but not the same, to it, you confuse the issue and
> make it more complicated than it need be.
>
>
> "Patrice" <http://www.chez.com/scribe/> wrote in message
> news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl...
>> OK I perhaps see a bit better your semantic point. AFAIK some additional
>> "markers" were suggested in SQL standards to better define various
>> meanings of "undefined", "unknown"," not applicable" or several other
>> semantics given to NULL values but never made into products...
>>
>> I perhaps miss also some nuances as English is not my native language but
>> hopefull the overall picture should be clear enough for the OP.
>>
>>
>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>> ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl...
>>> Something having an unknown value is not, in any way, related to a
>>> dissussion of null.  The very word you use "unkown" implies that there
>>> is, in fact, something to "know".  A null value indicates the exact
>>> opposite of that, that there is no value at all.  That's why I said that
>>> your alaogy was not a good one.
>>>
>>> When I run into situations where a value is unknown to me, I set up a
>>> variable to capture that value.  After doing that, I can then look to
>>> see if the varialbe is null, seven, "green" or anything else.  The fact
>>> that I didn't know the value of the variable does not imply null.
>>>
>>> You seem to be discussing what a "nullable type" is, rather than the
>>> meaning of "null".
>>>
>>>
>>>
>>>
>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl...
>>>> Not sure what you meant. How would you mark that the price is unknown
>>>> if not using a "nullable" type representing a null value ? As a side
>>>> note, an empty string is not a "null" string (in the first case we
>>>> known that the value is a zero length string, in the other case we
>>>> don't know what the value is).
>>>>
>>>> IMO one of the problem in discussing is that null has multiple
>>>> acceptances. In the context of a nullable type this is the same than
>>>> the "NULL" (Il'l use uppercase for this meaning) marker used in most
>>>> DB, not the "null" refererence as usual in C# (likely why MS used
>>>> HasValue for what is called "nullable" types toa void the ambiguity).
>>>> VB.NET uses the Nothing keyword.
>>>>
>>>> Finally I see sometimes what is IMO an abusive use of NULL. If you know
>>>> that you have no name suffix, you don't have to use a NULL value but an
>>>> empty string will do. You have to use a NULLable column if you want to
>>>> distinguish if the value is an empty string or if it has no meaning
>>>> (i.e. not "known", "applicable" or whatever semantic you attribute to
>>>> the NULL value).
>>>> ---
>>>> Patrice
>>>>
>>>>
>>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>>>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl...
>>>>>I would have to disagree with your analogy.
>>>>>
>>>>> If someting is free, it still has a value of zero dollars (as you
>>>>> say), but if we don't know the price, that doesn't make the price
>>>>> null, it just makes the price unkown.
>>>>>
>>>>> null is simply a keyword that indicates that the item in question does
>>>>> not have a relationship to any data at all.
>>>>>
>>>>> A = 0    <-- A has a value of zero
>>>>> A = " "   <-- A has a value of the space char
>>>>> A = ""    <-- A has a null value (no data at all)
>>>>>
>>>>> The benefit of null values is primarially when using databases, since
>>>>> most databases have tables where not all fields are required to have a
>>>>> value (like a middle name or apartment number or name suffix, such as
>>>>> Sr. or Jr.). Since it is possible that a field may be null, we need a
>>>>> way of checking it as such or passing null values into it.
>>>>>
>>>>> -Scott
>>>>>
>>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl...
>>>>>> For example for a price it would allow to distingusih between
>>>>>> something that is free (0) and something for which don't know the
>>>>>> price (null).
>>>>>>
>>>>>> It's likely you'll mostly use this for dates (if the vetn occured the
>>>>>> date will be filled, if the event didnt' occured date, the date will
>>>>>> be null).
>>>>>>
>>>>>> ---
>>>>>> Patrice
>>>>>>
>>>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de
>>>>>> news: 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
>>>>>>> hi,
>>>>>>> i'm a new bie to c#.net 2.0....
>>>>>>> i've come across a new feature by name nullable types...need some
>>>>>>> info on it
>>>>>>>
>>>>>>> what is actually a null value...
>>>>>>> what exactly is advantage we get by specifying a value type as a
>>>>>>> null value...
>>>>>>>
>>>>>>> please clarify
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Author
5 Apr 2007 3:19 PM
Scott M.
I think you are making my point here.  You introduced the concepts and
terms: "unknown", "undefined" and "not applicable" into the disussion. In
addition, you are talking about "why" a database needs the concept of a null
(I personally think you mis-stated that, but that is besides the point).

Below, you are talking about the practical use of null, rather than the
meaning of null, which is the point of this thread.


Show quoteHide quote
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:ecXux94dHHA.4032@TK2MSFTNGP02.phx.gbl...
> I'm not using null when "I don't know what value the user may want to
> input" (actually I never know what value the user will enter, not sure
> what you meant).
>
> Also I don't use NULL when "I'm letting the user not put any value at all
> into the field" which is IMO bad form at least to do systematically. I'll
> use an empty string or 0 as a default value if it makes senses.
>
> I will use this for example for the actual start date of something that
> not started yet. In  this case you can't provide any value. IMO this is a
> more convincing sample than Appartement number and the like where in a
> real world scenario you never want to distinguish between a value that
> can't be provided for some reason (null) and the fact that the apartment
> number is just an empty string because you *know* this is an empty string,
> not because you are unable to provide this value.
>
> This is perhaps why I tried at first to explain what's behind null. I felt
> that using simply the word "null" was perhaps not sufficient as it is IMO
> sometimes misused.
>
> ---
> Patrice
>
> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
> OTi6AT4dHHA.1***@TK2MSFTNGP04.phx.gbl...
>> Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," not
>> applicable" have never been identified with "null" in SQL or anywhere
>> else. When I mark a filed in SQL as "nullable", I am not doing it because
>> I don't know what value the user may want to put into the field.  On the
>> contrary, I do it because I'm letting the user not put any value at all
>> into the field.
>>
>> Again "undefined", "unknown"," not applicable" does not equal "null".  I
>> think this is super-important to be clear on, because "null" has a
>> special purpose and meaning and the minute you try to attach a meaning
>> that is something similiar, but not the same, to it, you confuse the
>> issue and make it more complicated than it need be.
>>
>>
>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>> news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl...
>>> OK I perhaps see a bit better your semantic point. AFAIK some additional
>>> "markers" were suggested in SQL standards to better define various
>>> meanings of "undefined", "unknown"," not applicable" or several other
>>> semantics given to NULL values but never made into products...
>>>
>>> I perhaps miss also some nuances as English is not my native language
>>> but hopefull the overall picture should be clear enough for the OP.
>>>
>>>
>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>>> ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl...
>>>> Something having an unknown value is not, in any way, related to a
>>>> dissussion of null.  The very word you use "unkown" implies that there
>>>> is, in fact, something to "know".  A null value indicates the exact
>>>> opposite of that, that there is no value at all.  That's why I said
>>>> that your alaogy was not a good one.
>>>>
>>>> When I run into situations where a value is unknown to me, I set up a
>>>> variable to capture that value.  After doing that, I can then look to
>>>> see if the varialbe is null, seven, "green" or anything else.  The fact
>>>> that I didn't know the value of the variable does not imply null.
>>>>
>>>> You seem to be discussing what a "nullable type" is, rather than the
>>>> meaning of "null".
>>>>
>>>>
>>>>
>>>>
>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>>> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl...
>>>>> Not sure what you meant. How would you mark that the price is unknown
>>>>> if not using a "nullable" type representing a null value ? As a side
>>>>> note, an empty string is not a "null" string (in the first case we
>>>>> known that the value is a zero length string, in the other case we
>>>>> don't know what the value is).
>>>>>
>>>>> IMO one of the problem in discussing is that null has multiple
>>>>> acceptances. In the context of a nullable type this is the same than
>>>>> the "NULL" (Il'l use uppercase for this meaning) marker used in most
>>>>> DB, not the "null" refererence as usual in C# (likely why MS used
>>>>> HasValue for what is called "nullable" types toa void the ambiguity).
>>>>> VB.NET uses the Nothing keyword.
>>>>>
>>>>> Finally I see sometimes what is IMO an abusive use of NULL. If you
>>>>> know that you have no name suffix, you don't have to use a NULL value
>>>>> but an empty string will do. You have to use a NULLable column if you
>>>>> want to distinguish if the value is an empty string or if it has no
>>>>> meaning (i.e. not "known", "applicable" or whatever semantic you
>>>>> attribute to the NULL value).
>>>>> ---
>>>>> Patrice
>>>>>
>>>>>
>>>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>>>>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl...
>>>>>>I would have to disagree with your analogy.
>>>>>>
>>>>>> If someting is free, it still has a value of zero dollars (as you
>>>>>> say), but if we don't know the price, that doesn't make the price
>>>>>> null, it just makes the price unkown.
>>>>>>
>>>>>> null is simply a keyword that indicates that the item in question
>>>>>> does not have a relationship to any data at all.
>>>>>>
>>>>>> A = 0    <-- A has a value of zero
>>>>>> A = " "   <-- A has a value of the space char
>>>>>> A = ""    <-- A has a null value (no data at all)
>>>>>>
>>>>>> The benefit of null values is primarially when using databases, since
>>>>>> most databases have tables where not all fields are required to have
>>>>>> a value (like a middle name or apartment number or name suffix, such
>>>>>> as Sr. or Jr.). Since it is possible that a field may be null, we
>>>>>> need a way of checking it as such or passing null values into it.
>>>>>>
>>>>>> -Scott
>>>>>>
>>>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>>>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl...
>>>>>>> For example for a price it would allow to distingusih between
>>>>>>> something that is free (0) and something for which don't know the
>>>>>>> price (null).
>>>>>>>
>>>>>>> It's likely you'll mostly use this for dates (if the vetn occured
>>>>>>> the date will be filled, if the event didnt' occured date, the date
>>>>>>> will be null).
>>>>>>>
>>>>>>> ---
>>>>>>> Patrice
>>>>>>>
>>>>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de
>>>>>>> news: 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
>>>>>>>> hi,
>>>>>>>> i'm a new bie to c#.net 2.0....
>>>>>>>> i've come across a new feature by name nullable types...need some
>>>>>>>> info on it
>>>>>>>>
>>>>>>>> what is actually a null value...
>>>>>>>> what exactly is advantage we get by specifying a value type as a
>>>>>>>> null value...
>>>>>>>>
>>>>>>>> please clarify
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Author
5 Apr 2007 4:22 PM
Patrice
I will just end with how the SQL Server doc explains this.

http://msdn2.microsoft.com/en-us/library/ms191504.aspx :
"Null values generally indicate data that is unknown, not applicable, or
that the data will be added later."

I'm not sure what is the point you don't like in this definition that looks
quite close to mine but it really looks like that understanding each other
on this topic is out of reach.

Take care and see you soon in another thread for another heated discussion
;-)

--
Patrice

"Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
OMPOZW5dHHA.4***@TK2MSFTNGP02.phx.gbl...
Show quoteHide quote
>I think you are making my point here.  You introduced the concepts and
>terms: "unknown", "undefined" and "not applicable" into the disussion. In
>addition, you are talking about "why" a database needs the concept of a
>null (I personally think you mis-stated that, but that is besides the
>point).
>
> Below, you are talking about the practical use of null, rather than the
> meaning of null, which is the point of this thread.
>
>
> "Patrice" <http://www.chez.com/scribe/> wrote in message
> news:ecXux94dHHA.4032@TK2MSFTNGP02.phx.gbl...
>> I'm not using null when "I don't know what value the user may want to
>> input" (actually I never know what value the user will enter, not sure
>> what you meant).
>>
>> Also I don't use NULL when "I'm letting the user not put any value at all
>> into the field" which is IMO bad form at least to do systematically. I'll
>> use an empty string or 0 as a default value if it makes senses.
>>
>> I will use this for example for the actual start date of something that
>> not started yet. In  this case you can't provide any value. IMO this is a
>> more convincing sample than Appartement number and the like where in a
>> real world scenario you never want to distinguish between a value that
>> can't be provided for some reason (null) and the fact that the apartment
>> number is just an empty string because you *know* this is an empty
>> string, not because you are unable to provide this value.
>>
>> This is perhaps why I tried at first to explain what's behind null. I
>> felt that using simply the word "null" was perhaps not sufficient as it
>> is IMO sometimes misused.
>>
>> ---
>> Patrice
>>
>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>> OTi6AT4dHHA.1***@TK2MSFTNGP04.phx.gbl...
>>> Hmmm, again, to my knowledge the concepts of "undefined", "unknown","
>>> not applicable" have never been identified with "null" in SQL or
>>> anywhere else. When I mark a filed in SQL as "nullable", I am not doing
>>> it because I don't know what value the user may want to put into the
>>> field.  On the contrary, I do it because I'm letting the user not put
>>> any value at all into the field.
>>>
>>> Again "undefined", "unknown"," not applicable" does not equal "null".  I
>>> think this is super-important to be clear on, because "null" has a
>>> special purpose and meaning and the minute you try to attach a meaning
>>> that is something similiar, but not the same, to it, you confuse the
>>> issue and make it more complicated than it need be.
>>>
>>>
>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>> news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl...
>>>> OK I perhaps see a bit better your semantic point. AFAIK some
>>>> additional "markers" were suggested in SQL standards to better define
>>>> various meanings of "undefined", "unknown"," not applicable" or several
>>>> other semantics given to NULL values but never made into products...
>>>>
>>>> I perhaps miss also some nuances as English is not my native language
>>>> but hopefull the overall picture should be clear enough for the OP.
>>>>
>>>>
>>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>>>> ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl...
>>>>> Something having an unknown value is not, in any way, related to a
>>>>> dissussion of null.  The very word you use "unkown" implies that there
>>>>> is, in fact, something to "know".  A null value indicates the exact
>>>>> opposite of that, that there is no value at all.  That's why I said
>>>>> that your alaogy was not a good one.
>>>>>
>>>>> When I run into situations where a value is unknown to me, I set up a
>>>>> variable to capture that value.  After doing that, I can then look to
>>>>> see if the varialbe is null, seven, "green" or anything else.  The
>>>>> fact that I didn't know the value of the variable does not imply null.
>>>>>
>>>>> You seem to be discussing what a "nullable type" is, rather than the
>>>>> meaning of "null".
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>>>> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl...
>>>>>> Not sure what you meant. How would you mark that the price is unknown
>>>>>> if not using a "nullable" type representing a null value ? As a side
>>>>>> note, an empty string is not a "null" string (in the first case we
>>>>>> known that the value is a zero length string, in the other case we
>>>>>> don't know what the value is).
>>>>>>
>>>>>> IMO one of the problem in discussing is that null has multiple
>>>>>> acceptances. In the context of a nullable type this is the same than
>>>>>> the "NULL" (Il'l use uppercase for this meaning) marker used in most
>>>>>> DB, not the "null" refererence as usual in C# (likely why MS used
>>>>>> HasValue for what is called "nullable" types toa void the ambiguity).
>>>>>> VB.NET uses the Nothing keyword.
>>>>>>
>>>>>> Finally I see sometimes what is IMO an abusive use of NULL. If you
>>>>>> know that you have no name suffix, you don't have to use a NULL value
>>>>>> but an empty string will do. You have to use a NULLable column if you
>>>>>> want to distinguish if the value is an empty string or if it has no
>>>>>> meaning (i.e. not "known", "applicable" or whatever semantic you
>>>>>> attribute to the NULL value).
>>>>>> ---
>>>>>> Patrice
>>>>>>
>>>>>>
>>>>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>>>>>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl...
>>>>>>>I would have to disagree with your analogy.
>>>>>>>
>>>>>>> If someting is free, it still has a value of zero dollars (as you
>>>>>>> say), but if we don't know the price, that doesn't make the price
>>>>>>> null, it just makes the price unkown.
>>>>>>>
>>>>>>> null is simply a keyword that indicates that the item in question
>>>>>>> does not have a relationship to any data at all.
>>>>>>>
>>>>>>> A = 0    <-- A has a value of zero
>>>>>>> A = " "   <-- A has a value of the space char
>>>>>>> A = ""    <-- A has a null value (no data at all)
>>>>>>>
>>>>>>> The benefit of null values is primarially when using databases,
>>>>>>> since most databases have tables where not all fields are required
>>>>>>> to have a value (like a middle name or apartment number or name
>>>>>>> suffix, such as Sr. or Jr.). Since it is possible that a field may
>>>>>>> be null, we need a way of checking it as such or passing null values
>>>>>>> into it.
>>>>>>>
>>>>>>> -Scott
>>>>>>>
>>>>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>>>>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl...
>>>>>>>> For example for a price it would allow to distingusih between
>>>>>>>> something that is free (0) and something for which don't know the
>>>>>>>> price (null).
>>>>>>>>
>>>>>>>> It's likely you'll mostly use this for dates (if the vetn occured
>>>>>>>> the date will be filled, if the event didnt' occured date, the date
>>>>>>>> will be null).
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Patrice
>>>>>>>>
>>>>>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de
>>>>>>>> news: 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
>>>>>>>>> hi,
>>>>>>>>> i'm a new bie to c#.net 2.0....
>>>>>>>>> i've come across a new feature by name nullable types...need some
>>>>>>>>> info on it
>>>>>>>>>
>>>>>>>>> what is actually a null value...
>>>>>>>>> what exactly is advantage we get by specifying a value type as a
>>>>>>>>> null value...
>>>>>>>>>
>>>>>>>>> please clarify
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Author
5 Apr 2007 4:33 PM
Rory Becker
> I will just end with how the SQL Server doc explains this.
>
> http://msdn2.microsoft.com/en-us/library/ms191504.aspx :
>
> "Null values generally indicate data that is unknown, not applicable,
> or that the data will be added later."

I really like that definition. It feels closest to what I think it should
mean.

--
Rory
Author
5 Apr 2007 5:11 PM
Scott M.
But (again) that is SQL definition of what a null value *indicates*, not of
what a the *definition* of null is.  It is also limited to SQL, not the .NET
Framework.

This documentation essentially says "Use null as an indication of the
following separate and different things...".  That, in no way is a defition
of what null represents.

Wouldn't you agree that "an unknown value" could be a value of 27?  Is 27
null?  So, I would say that the documentation is actually poorly written
(wouldn't be the first time).




Show quoteHide quote
"Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message
news:b0ac48a083368c945bfa70ac670@msnews.microsoft.com...
>> I will just end with how the SQL Server doc explains this.
>>
>> http://msdn2.microsoft.com/en-us/library/ms191504.aspx :
>>
>> "Null values generally indicate data that is unknown, not applicable,
>> or that the data will be added later."
>
> I really like that definition. It feels closest to what I think it should
> mean.
>
> --
> Rory
>
>
Author
5 Apr 2007 6:15 PM
Patrice
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. Once you know the value is 27,
you'll have 27. I don't see how it would make 27 equal to null. Looks like
as simple as that to me.

Of course if you wanted to distinguish additional cases ("not know", "not
applicable" etc...) you would have to keep an additional value acting as a
marker but I've never have to do this myself until then.

My understanding is that the OP wasn't discussing the null C# keyword but
the 2.0 "nullable types" feature
(http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx) that allows to mark
a value type as being "null"? I would be very inclined to think that it were
precisely introduced to match the NULL marker found DBMS sidea nd that
wasn't available .NET side for value types until now.

Finally I would think he was expecting a bit more than a "formal definition"
(what is yours ?) but sorry we are not allowed to tell you what this value
could "indicate" in practice in your code...

I have nothing to add...

--
Patrice

"Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
uH02rU6dHHA.3***@TK2MSFTNGP03.phx.gbl...
Show quoteHide quote
> But (again) that is SQL definition of what a null value *indicates*, not
> of what a the *definition* of null is.  It is also limited to SQL, not the
> .NET Framework.
>
> This documentation essentially says "Use null as an indication of the
> following separate and different things...".  That, in no way is a
> defition of what null represents.
>
> Wouldn't you agree that "an unknown value" could be a value of 27?  Is 27
> null?  So, I would say that the documentation is actually poorly written
> (wouldn't be the first time).
>
>
>
>
> "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message
> news:b0ac48a083368c945bfa70ac670@msnews.microsoft.com...
>>> I will just end with how the SQL Server doc explains this.
>>>
>>> http://msdn2.microsoft.com/en-us/library/ms191504.aspx :
>>>
>>> "Null values generally indicate data that is unknown, not applicable,
>>> or that the data will be added later."
>>
>> I really like that definition. It feels closest to what I think it should
>> mean.
>>
>> --
>> Rory
>>
>>
>
>
Author
5 Apr 2007 6:39 PM
Jon Skeet [C# MVP]
<snip>

> My understanding is that the OP wasn't discussing the null C# keyword but
> the 2.0 "nullable types" feature
> (http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx) that allows to mark
> a value type as being "null"? I would be very inclined to think that it were
> precisely introduced to match the NULL marker found DBMS sidea nd that
> wasn't available .NET side for value types until now.

I would largely agree, but soften the statement a little. It doesn't
really "match" NULL in the database, but it's often used to represent a
value which is NULL in a database (or which should be NULL after
insertion/update).

The rules for equality and logic are different to databases (and are
also different in different languages, IIRC). A good example of this is
the following program - it will produce output of "True", but a query
trying to match using "=" in SQL wouldn't work:

using System;

class Program
{   
    static void Main(string[] args)
    {
        int? x = null;

        Console.WriteLine (x==null);
    }
}

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
5 Apr 2007 8:05 PM
Scott M.
> 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?

> Of course if you wanted to distinguish additional cases ("not know", "not
> applicable" etc...) you would have to keep an additional value acting as a
> marker but I've never have to do this myself until then.

Again, you are making my point!  You just said that to distinguish these
other possibilities, you need some value acting as a marker, null is not
sufficient for all these possibilities so how could your documentation be a
good one for null.

> My understanding is that the OP wasn't discussing the null C# keyword but
> the 2.0 "nullable types" feature
> (http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx) that allows to
> mark a value type as being "null"? I would be very inclined to think that
> it were precisely introduced to match the NULL marker found DBMS sidea nd
> that wasn't available .NET side for value types until now.
>
> Finally I would think he was expecting a bit more than a "formal
> definition" (what is yours ?)

I'm pretty sure I've said this a bunch of times at this point:

null = no value

> but sorry we are not allowed to tell you what this value could "indicate"
> in practice in your code...

You could, but that wouldn't be a definition of null (as the OP asked "what
is actually a null value").  You have not provided a definition of null
anywhere in your replies, just places where you *could* use null.  Strange
that you are asking me for something I've given, but not given yourself?

Show quoteHide quote
>
> I have nothing to add...
>
> --
> Patrice
>
> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
> uH02rU6dHHA.3***@TK2MSFTNGP03.phx.gbl...
>> But (again) that is SQL definition of what a null value *indicates*, not
>> of what a the *definition* of null is.  It is also limited to SQL, not
>> the .NET Framework.
>>
>> This documentation essentially says "Use null as an indication of the
>> following separate and different things...".  That, in no way is a
>> defition of what null represents.
>>
>> Wouldn't you agree that "an unknown value" could be a value of 27?  Is 27
>> null?  So, I would say that the documentation is actually poorly written
>> (wouldn't be the first time).
>>
>>
>>
>>
>> "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message
>> news:b0ac48a083368c945bfa70ac670@msnews.microsoft.com...
>>>> I will just end with how the SQL Server doc explains this.
>>>>
>>>> http://msdn2.microsoft.com/en-us/library/ms191504.aspx :
>>>>
>>>> "Null values generally indicate data that is unknown, not applicable,
>>>> or that the data will be added later."
>>>
>>> I really like that definition. It feels closest to what I think it
>>> should mean.
>>>
>>> --
>>> Rory
>>>
>>>
>>
>>
>
>
Author
5 Apr 2007 8:49 PM
Rory Becker
>> 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 :P

[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 :D

--
Rory
Author
5 Apr 2007 8:59 PM
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.


Show quoteHide quote
"Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message
news:b0ac48a0838e8c945e37bdb4550@msnews.microsoft.com...
>>> 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 :P
>
> [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 :D
>
> --
> Rory
>
>
>
Author
6 Apr 2007 12:49 PM
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.


"Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
ua$DSU8dHHA.4***@TK2MSFTNGP04.phx.gbl...
Show quoteHide quote
> 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.
>
>
> "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message
> news:b0ac48a0838e8c945e37bdb4550@msnews.microsoft.com...
>>>> 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 :P
>>
>> [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 :D
>>
>> --
>> Rory
>>
>>
>>
>
>
Author
6 Apr 2007 2:40 PM
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.


Show quoteHide quote
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:O%23db3nEeHHA.1216@TK2MSFTNGP03.phx.gbl...
> 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.
>
>
> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
> ua$DSU8dHHA.4***@TK2MSFTNGP04.phx.gbl...
>> 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.
>>
>>
>> "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message
>> news:b0ac48a0838e8c945e37bdb4550@msnews.microsoft.com...
>>>>> 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 :P
>>>
>>> [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 :D
>>>
>>> --
>>> Rory
>>>
>>>
>>>
>>
>>
>
>
Author
6 Apr 2007 3:26 PM
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.


Show quoteHide quote
"Scott M." <s-mar@nospam.nospam> wrote in message
news:OtdFclFeHHA.4172@TK2MSFTNGP05.phx.gbl...
> 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.
>
>
> "Patrice" <http://www.chez.com/scribe/> wrote in message
> news:O%23db3nEeHHA.1216@TK2MSFTNGP03.phx.gbl...
>> 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.
>>
>>
>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>> ua$DSU8dHHA.4***@TK2MSFTNGP04.phx.gbl...
>>> 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.
>>>
>>>
>>> "Rory Becker" <RoryBecker@newsgroup.nospam> wrote in message
>>> news:b0ac48a0838e8c945e37bdb4550@msnews.microsoft.com...
>>>>>> 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 :P
>>>>
>>>> [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 :D
>>>>
>>>> --
>>>> Rory
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Author
6 Apr 2007 12:47 PM
Patrice
Well no. This is actually the same as Patrick here in France. The feminim
form for us is Patricia.

"Rory Becker" <RoryBecker@newsgroup.nospam> a écrit dans le message de news:
b0ac48a0838e8c945e37bdb4***@msnews.microsoft.com...
Show quoteHide quote
>>> 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 :P
>
> [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 :D
>
> --
> Rory
>
>
>
Author
5 Apr 2007 4:33 PM
Scott M.
"Patrice" <http://www.chez.com/scribe/> wrote in message
news:edMkW65dHHA.4032@TK2MSFTNGP02.phx.gbl...
>I will just end with how the SQL Server doc explains this.
>
> http://msdn2.microsoft.com/en-us/library/ms191504.aspx :
> "Null values generally indicate data that is unknown, not applicable, or
> that the data will be added later."
>
> I'm not sure what is the point you don't like in this definition that
> looks quite close to mine but it really looks like that understanding each
> other on this topic is out of reach.

What I don't like is exactly what I've been saying all along, we're not
talking about what a null value in SQL "INDICATES" (per your documentation).
So your definition and link are irrelevant.   We are talking about the
DEFINITION of null in the .NET FRAMEWORK.  What if another database's
documentation had a different description of null?  Would that change your
understanding of what null means?

>
> Take care and see you soon in another thread for another heated discussion
> ;-)

You too!


Show quoteHide quote
>
> --
> Patrice
>
> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
> OMPOZW5dHHA.4***@TK2MSFTNGP02.phx.gbl...
>>I think you are making my point here.  You introduced the concepts and
>>terms: "unknown", "undefined" and "not applicable" into the disussion. In
>>addition, you are talking about "why" a database needs the concept of a
>>null (I personally think you mis-stated that, but that is besides the
>>point).
>>
>> Below, you are talking about the practical use of null, rather than the
>> meaning of null, which is the point of this thread.
>>
>>
>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>> news:ecXux94dHHA.4032@TK2MSFTNGP02.phx.gbl...
>>> I'm not using null when "I don't know what value the user may want to
>>> input" (actually I never know what value the user will enter, not sure
>>> what you meant).
>>>
>>> Also I don't use NULL when "I'm letting the user not put any value at
>>> all into the field" which is IMO bad form at least to do systematically.
>>> I'll use an empty string or 0 as a default value if it makes senses.
>>>
>>> I will use this for example for the actual start date of something that
>>> not started yet. In  this case you can't provide any value. IMO this is
>>> a more convincing sample than Appartement number and the like where in a
>>> real world scenario you never want to distinguish between a value that
>>> can't be provided for some reason (null) and the fact that the apartment
>>> number is just an empty string because you *know* this is an empty
>>> string, not because you are unable to provide this value.
>>>
>>> This is perhaps why I tried at first to explain what's behind null. I
>>> felt that using simply the word "null" was perhaps not sufficient as it
>>> is IMO sometimes misused.
>>>
>>> ---
>>> Patrice
>>>
>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>>> OTi6AT4dHHA.1***@TK2MSFTNGP04.phx.gbl...
>>>> Hmmm, again, to my knowledge the concepts of "undefined", "unknown","
>>>> not applicable" have never been identified with "null" in SQL or
>>>> anywhere else. When I mark a filed in SQL as "nullable", I am not doing
>>>> it because I don't know what value the user may want to put into the
>>>> field.  On the contrary, I do it because I'm letting the user not put
>>>> any value at all into the field.
>>>>
>>>> Again "undefined", "unknown"," not applicable" does not equal "null".
>>>> I think this is super-important to be clear on, because "null" has a
>>>> special purpose and meaning and the minute you try to attach a meaning
>>>> that is something similiar, but not the same, to it, you confuse the
>>>> issue and make it more complicated than it need be.
>>>>
>>>>
>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>>> news:%23wpuDg1dHHA.1868@TK2MSFTNGP04.phx.gbl...
>>>>> OK I perhaps see a bit better your semantic point. AFAIK some
>>>>> additional "markers" were suggested in SQL standards to better define
>>>>> various meanings of "undefined", "unknown"," not applicable" or
>>>>> several other semantics given to NULL values but never made into
>>>>> products...
>>>>>
>>>>> I perhaps miss also some nuances as English is not my native language
>>>>> but hopefull the overall picture should be clear enough for the OP.
>>>>>
>>>>>
>>>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>>>>> ulQ8h4udHHA.***@TK2MSFTNGP05.phx.gbl...
>>>>>> Something having an unknown value is not, in any way, related to a
>>>>>> dissussion of null.  The very word you use "unkown" implies that
>>>>>> there is, in fact, something to "know".  A null value indicates the
>>>>>> exact opposite of that, that there is no value at all.  That's why I
>>>>>> said that your alaogy was not a good one.
>>>>>>
>>>>>> When I run into situations where a value is unknown to me, I set up a
>>>>>> variable to capture that value.  After doing that, I can then look to
>>>>>> see if the varialbe is null, seven, "green" or anything else.  The
>>>>>> fact that I didn't know the value of the variable does not imply
>>>>>> null.
>>>>>>
>>>>>> You seem to be discussing what a "nullable type" is, rather than the
>>>>>> meaning of "null".
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>>>>> news:esbV%23RudHHA.4188@TK2MSFTNGP02.phx.gbl...
>>>>>>> Not sure what you meant. How would you mark that the price is
>>>>>>> unknown if not using a "nullable" type representing a null value ?
>>>>>>> As a side note, an empty string is not a "null" string (in the first
>>>>>>> case we known that the value is a zero length string, in the other
>>>>>>> case we don't know what the value is).
>>>>>>>
>>>>>>> IMO one of the problem in discussing is that null has multiple
>>>>>>> acceptances. In the context of a nullable type this is the same than
>>>>>>> the "NULL" (Il'l use uppercase for this meaning) marker used in most
>>>>>>> DB, not the "null" refererence as usual in C# (likely why MS used
>>>>>>> HasValue for what is called "nullable" types toa void the
>>>>>>> ambiguity). VB.NET uses the Nothing keyword.
>>>>>>>
>>>>>>> Finally I see sometimes what is IMO an abusive use of NULL. If you
>>>>>>> know that you have no name suffix, you don't have to use a NULL
>>>>>>> value but an empty string will do. You have to use a NULLable column
>>>>>>> if you want to distinguish if the value is an empty string or if it
>>>>>>> has no meaning (i.e. not "known", "applicable" or whatever semantic
>>>>>>> you attribute to the NULL value).
>>>>>>> ---
>>>>>>> Patrice
>>>>>>>
>>>>>>>
>>>>>>> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
>>>>>>> %23NBysutdHHA.4***@TK2MSFTNGP03.phx.gbl...
>>>>>>>>I would have to disagree with your analogy.
>>>>>>>>
>>>>>>>> If someting is free, it still has a value of zero dollars (as you
>>>>>>>> say), but if we don't know the price, that doesn't make the price
>>>>>>>> null, it just makes the price unkown.
>>>>>>>>
>>>>>>>> null is simply a keyword that indicates that the item in question
>>>>>>>> does not have a relationship to any data at all.
>>>>>>>>
>>>>>>>> A = 0    <-- A has a value of zero
>>>>>>>> A = " "   <-- A has a value of the space char
>>>>>>>> A = ""    <-- A has a null value (no data at all)
>>>>>>>>
>>>>>>>> The benefit of null values is primarially when using databases,
>>>>>>>> since most databases have tables where not all fields are required
>>>>>>>> to have a value (like a middle name or apartment number or name
>>>>>>>> suffix, such as Sr. or Jr.). Since it is possible that a field may
>>>>>>>> be null, we need a way of checking it as such or passing null
>>>>>>>> values into it.
>>>>>>>>
>>>>>>>> -Scott
>>>>>>>>
>>>>>>>> "Patrice" <http://www.chez.com/scribe/> wrote in message
>>>>>>>> news:uiUEhoqdHHA.1220@TK2MSFTNGP03.phx.gbl...
>>>>>>>>> For example for a price it would allow to distingusih between
>>>>>>>>> something that is free (0) and something for which don't know the
>>>>>>>>> price (null).
>>>>>>>>>
>>>>>>>>> It's likely you'll mostly use this for dates (if the vetn occured
>>>>>>>>> the date will be filled, if the event didnt' occured date, the
>>>>>>>>> date will be null).
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> Patrice
>>>>>>>>>
>>>>>>>>> "AVL" <A**@discussions.microsoft.com> a écrit dans le message de
>>>>>>>>> news: 49380D43-FF22-4652-98B0-82E7C30DE***@microsoft.com...
>>>>>>>>>> hi,
>>>>>>>>>> i'm a new bie to c#.net 2.0....
>>>>>>>>>> i've come across a new feature by name nullable types...need some
>>>>>>>>>> info on it
>>>>>>>>>>
>>>>>>>>>> what is actually a null value...
>>>>>>>>>> what exactly is advantage we get by specifying a value type as a
>>>>>>>>>> null value...
>>>>>>>>>>
>>>>>>>>>> please clarify
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Author
5 Apr 2007 2:42 PM
Jon Skeet [C# MVP]
On Apr 5, 2:19 pm, "Scott M." <s...@nospam.nospam> wrote:
> Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," not
> applicable" have never been identified with "null" in SQL or anywhere else.
> When I mark a filed in SQL as "nullable", I am not doing it because I don't
> know what value the user may want to put into the field.  On the contrary, I
> do it because I'm letting the user not put any value at all into the field.
>
> Again "undefined", "unknown"," not applicable" does not equal "null".  I
> think this is super-important to be clear on, because "null" has a special
> purpose and meaning and the minute you try to attach a meaning that is
> something similiar, but not the same, to it, you confuse the issue and make
> it more complicated than it need be.

Note that the same issue of confusion and complicated is true when
mixing the NULL of a database with the null of C#.
For instance, nulls are equal to each other in C#/.NET, but not in a
database (where you need IS NULL or whatever).

I think it's worth leaving databases out of the discussion, personally
- at least until we get into why nullable types were a widely
requested feature.

Jon
Author
5 Apr 2007 4:12 PM
Peter Duniho
On Wed, 04 Apr 2007 12:20:48 -0700, Scott M. <s-mar@nospam.nospam> wrote:

> Something having an unknown value is not, in any way, related to a
> dissussion of null.  The very word you use "unkown" implies that there 
> is, in fact, something to "know".  A null value indicates the exact
> opposite of that, that there is no value at all.  That's why I said
> that your alaogy was not a good one.

IMHO, you are making a mountain out of a molehill.

The exact meaning of "null" depends on what the designer of the code using 
"null" intends it to mean.  While I do see the difference between 
something having a price that is not known and something not having a 
price at all, I see absolutely nothing wrong with someone writing code in 
which "null" can mean the former.  For example, suppose you have a 
database of products available for sale.  You know ahead of time that 
*everything* has a price.  Why in the world would you use "null" to 
indicate something that has no price?  Your set of data would never use 
the value "null" in that case, and there would be no reason to even use a 
nullable type.

"Null" means what the code designer says it means.  Nothing more, nothing 
less.  Your complaint about the analogy provided is pointless.  If someone 
wants to use a "null" value to indicate that a value is unknown, rather 
than to indicate that there is no value, what's it to you?  How in the 
world is it so wrong to do so?

> When I run into situations where a value is unknown to me, I set up a
> variable to capture that value. [...]

And what if according to your definition of "null", your variable will 
never take on the value "null"?  Then you've wasted extra storage for no 
good reason.

> You seem to be discussing what a "nullable type" is, rather than the 
> meaning of "null".

Given that "the meaning of 'null'" is arbitrary, while "what a 'nullable 
type' is" is not arbitrary, it seems to me that the latter is a more 
sensible thing to discuss.

Pete
Author
5 Apr 2007 4:39 PM
Scott M.
> "Null" means what the code designer says it means.  Nothing more, nothing
> less.  Your complaint about the analogy provided is pointless.  If someone
> wants to use a "null" value to indicate that a value is unknown, rather
> than to indicate that there is no value, what's it to you?  How in the
> world is it so wrong to do so?

Because "null" is not a term that I coined, it is a well known programming
concept and it doesn't "mean" whatever the designer wants, it means "no
value at all" - nothing more, nothing less.  That is not my definition, it
is the programming definition.  Now, it would be fair to say that a designer
can *use* nulls as they see fit for their application, but the desinger
never gets to *define* the meaning of null.

> Given that "the meaning of 'null'" is arbitrary, while "what a 'nullable
> type' is" is not arbitrary, it seems to me that the latter is a more
> sensible thing to discuss.

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.
Author
5 Apr 2007 4:54 PM
Jon Skeet [C# MVP]
Scott M. <s-mar@nospam.nospam> wrote:
> > "Null" means what the code designer says it means.  Nothing more, nothing
> > less.  Your complaint about the analogy provided is pointless.  If someone
> > wants to use a "null" value to indicate that a value is unknown, rather
> > than to indicate that there is no value, what's it to you?  How in the
> > world is it so wrong to do so?
>
> Because "null" is not a term that I coined, it is a well known programming
> concept and it doesn't "mean" whatever the designer wants, it means "no
> value at all" - nothing more, nothing less.  That is not my definition, it
> is the programming definition.

Um, it's not the definition in either the C# spec or the CLI spec. That
defines it as a special value which indicates the absence of an
instance. Quite precise, and not the same as "no value at all".

Could you give a reference to where your definition comes from and why
it should be seen as more authoritative than the C#/CLI specs in a
discussion about C# and the CLI?

Other languages can define it in other ways (C++, for instance, defines
null pointers, null characters etc) which is why it's worth sticking to
the specification of the platform/language in question.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
5 Apr 2007 5:17 PM
Scott M.
John, I'm not going to split unecessary hairs with you, yet again.  Contrary
to your statement, I believe that (in programming terms) saying something
has no value at all and something not pointing to an instace are, in fact,
saying the same thing.

The point of my last comment is that the statement ""Null" means what the
code designer says it means." and the statment "Given that "the meaning of
'null'" is arbitrary" are both incorrect.




Show quoteHide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MPG.207f39fecf1a982c98da87@msnews.microsoft.com...
> Scott M. <s-mar@nospam.nospam> wrote:
>> > "Null" means what the code designer says it means.  Nothing more,
>> > nothing
>> > less.  Your complaint about the analogy provided is pointless.  If
>> > someone
>> > wants to use a "null" value to indicate that a value is unknown, rather
>> > than to indicate that there is no value, what's it to you?  How in the
>> > world is it so wrong to do so?
>>
>> Because "null" is not a term that I coined, it is a well known
>> programming
>> concept and it doesn't "mean" whatever the designer wants, it means "no
>> value at all" - nothing more, nothing less.  That is not my definition,
>> it
>> is the programming definition.
>
> Um, it's not the definition in either the C# spec or the CLI spec. That
> defines it as a special value which indicates the absence of an
> instance. Quite precise, and not the same as "no value at all".
>
> Could you give a reference to where your definition comes from and why
> it should be seen as more authoritative than the C#/CLI specs in a
> discussion about C# and the CLI?
>
> Other languages can define it in other ways (C++, for instance, defines
> null pointers, null characters etc) which is why it's worth sticking to
> the specification of the platform/language in question.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too
Author
5 Apr 2007 6:17 PM
Jon Skeet [C# MVP]
Scott M. <s-mar@nospam.nospam> wrote:
> John, I'm not going to split unecessary hairs with you, yet again.  Contrary
> to your statement, I believe that (in programming terms) saying something
> has no value at all and something not pointing to an instace are, in fact,
> saying the same thing.

Do you not see how "no value at all" and "a special value" are
contradictions? According to the C# spec at least, null *is* a value.
To say it's not a value contradicts that.

If I do:

string x = null;

then the variable x has a value - the null value, which refers to no
instance.

If I do:

string x;

then the variable x has no assigned value yet, as far as C# is
concerned.

> The point of my last comment is that the statement ""Null" means what the
> code designer says it means." and the statment "Given that "the meaning of
> 'null'" is arbitrary" are both incorrect.

On that point I agree with Peter - that it's reasonable to say (in a
particular situation) what semantic meaning a "null" value has, how it
should be interpreted for that particular variable/return value etc. On
this point, it seems to me that you're the one splitting hairs.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
5 Apr 2007 8:17 PM
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".




Show quoteHide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MPG.207f4da7e1b9848098da89@msnews.microsoft.com...
> Scott M. <s-mar@nospam.nospam> wrote:
>> John, I'm not going to split unecessary hairs with you, yet again.
>> Contrary
>> to your statement, I believe that (in programming terms) saying something
>> has no value at all and something not pointing to an instace are, in
>> fact,
>> saying the same thing.
>
> Do you not see how "no value at all" and "a special value" are
> contradictions? According to the C# spec at least, null *is* a value.
> To say it's not a value contradicts that.
>
> If I do:
>
> string x = null;
>
> then the variable x has a value - the null value, which refers to no
> instance.
>
> If I do:
>
> string x;
>
> then the variable x has no assigned value yet, as far as C# is
> concerned.
>
>> The point of my last comment is that the statement ""Null" means what the
>> code designer says it means." and the statment "Given that "the meaning
>> of
>> 'null'" is arbitrary" are both incorrect.
>
> On that point I agree with Peter - that it's reasonable to say (in a
> particular situation) what semantic meaning a "null" value has, how it
> should be interpreted for that particular variable/return value etc. On
> this point, it seems to me that you're the one splitting hairs.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too
Author
5 Apr 2007 8:32 PM
Jon Skeet [C# MVP]
Scott M. <s-mar@nospam.nospam> wrote:
> 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_%28computer%29

<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".

Show quoteHide quote
> 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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
5 Apr 2007 8:52 PM
Scott M.
Please fill in the blank with a specific value:

null = _____

Thank you.

Show quoteHide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MPG.207f6d4168fb890b98da8d@msnews.microsoft.com...
> Scott M. <s-mar@nospam.nospam> wrote:
>> 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_%28computer%29
>
> <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?
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too
Author
5 Apr 2007 9:00 PM
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 = _____;



Show quoteHide quote
"Scott M." <s-mar@nospam.nospam> wrote in message
news:uD7XKQ8dHHA.4772@TK2MSFTNGP05.phx.gbl...
> Please fill in the blank with a specific value:
>
> null = _____
>
> Thank you.
>
> "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> news:MPG.207f6d4168fb890b98da8d@msnews.microsoft.com...
>> Scott M. <s-mar@nospam.nospam> wrote:
>>> 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_%28computer%29
>>
>> <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?
>>
>> --
>> Jon Skeet - <sk***@pobox.com>
>> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
>> If replying to the group, please do not mail me too
>
>
Author
5 Apr 2007 9:07 PM
Jon Skeet [C# MVP]
Scott M. <s-mar@nospam.nospam> wrote:
> 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 - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
5 Apr 2007 8:56 PM
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.


Show quoteHide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MPG.207f6d4168fb890b98da8d@msnews.microsoft.com...
> Scott M. <s-mar@nospam.nospam> wrote:
>> 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_%28computer%29
>
> <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?
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too
Author
5 Apr 2007 9:08 PM
Jon Skeet [C# MVP]
Scott M. <s-mar@nospam.nospam> wrote:
> 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?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
5 Apr 2007 10:44 PM
Scott M.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MPG.207f75c61d7b899198da91@msnews.microsoft.com...
> Scott M. <s-mar@nospam.nospam> wrote:
>> 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?

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.



Show quoteHide quote
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too
Author
6 Apr 2007 6:18 AM
Jon Skeet [C# MVP]
Scott M. <s-mar@nospam.nospam> wrote:
> > 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.

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.

> > 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?

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
5 Apr 2007 4:54 PM
Peter Duniho
On Thu, 05 Apr 2007 09:39:24 -0700, Scott M. <s-mar@nospam.nospam> wrote:

> [...]
> 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.

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.

Pete
Author
5 Apr 2007 8:25 PM
Scott M.
Show quote Hide quote
"Peter Duniho" <NpOeStPe***@nnowslpianmk.com> wrote in message
news:op.tqbk9ra38jd0ej@petes-computer.local...
> On Thu, 05 Apr 2007 09:39:24 -0700, Scott M. <s-mar@nospam.nospam> wrote:
>
>> [...]
>> 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.

Show quoteHide quote
>
> Pete
Author
5 Apr 2007 11:35 PM
Peter Duniho
On Thu, 05 Apr 2007 13:25:24 -0700, Scott M. <s-mar@nospam.nospam> wrote=
Show quoteHide quote
:

> [...]
>> 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 SAM=
E  =

>> as what the coder using the "null" value to indicate and has ABSOLUTE=
LY
>> 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 ou=
t  =

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 =3D
> 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 perfec=
tly
> good example of how and why one might initialize something as null, bu=
t  =

> 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 o=
f  =

his post adds absolutely zero to anyone's understanding of what a nullab=
le  =

type is or how it might be used.

Pete
Author
6 Apr 2007 1:12 AM
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.
Author
4 Apr 2007 11:32 AM
Kevin Spencer
First of all, a null value is nothing. That is, it indicates that a variable
or reference to data of a given type is unassigned, and therefore has no
value. As for what the advantage is, you have to understand a bit about
reference types and value types to understand nullable types. A reference
type (such as a class) is a type that is referenced by a managed pointer,
and stored in the heap. A value type (such as int, char, and array) is a
type that is referenced directly by its' actual value on the stack. So,
while a pointer can point to nothing, an integer is an allocation of 32 bits
of memory on the stack, and will always have a value, since a bit is either
a 1 or a 0.

However, a value type is actually a class that is treated like a "classic"
value type. So, it is possible to assign a null value (pointer) to a value
type, although it took some additional manipulation of the .Net Framework to
allow this behavior.

There is no advantage necessarily to nullable types, except where they may
be useful. For example, most databases these days allow a null value to be
stored for data in a table, including integers, strings, and dates. It is
helpful, when interacting with a database, to be able to assign a null value
to the variables which interact with the database.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

Show quoteHide quote
"AVL" <A**@discussions.microsoft.com> wrote in message
news:49380D43-FF22-4652-98B0-82E7C30DEC82@microsoft.com...
> hi,
> i'm a new bie to c#.net 2.0....
> i've come across a new feature by name nullable types...need some info on
> it
>
> what is actually a null value...
> what exactly is advantage we get by specifying a value type as a null
> value...
>
> please clarify
Author
4 Apr 2007 5:04 PM
Jon Skeet [C# MVP]
Kevin Spencer <unclechut***@nothinks.com> wrote:
> First of all, a null value is nothing. That is, it indicates that a variable
> or reference to data of a given type is unassigned, and therefore has no
> value.

I'd disagree with that - being unassigned is very different to being
assigned the value null. Take:

string x;

string x = null;

(Where x is a local variable.)

In the first case, the variable is unassigned. In the second case, it
is definitely assigned with a value of null, which is the value which
doesn't refer to any object.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
4 Apr 2007 9:35 PM
Kevin Spencer
I'll have to take issue with you here, Jon. Null is not a value technically
speaking, as a value is something. If you declare a string variable without
initializing it, and test it for null, it will return true. While null
doesn't have exactly the same technical meaning that it used to have back in
the days of "simple" C programming, it still signifies nothing, and an
unassigned variable is nothing. You can't make a distinction between nothing
and nothing, and the compiler doesn't either. There are situations in which
the compiler will insist that you assign a null value to a variable, but
those are "safety" checks, and it isn't consistent, as there are other times
when it will not, and will test true for null with an unassigned variable.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net


Show quoteHide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MPG.207deb14e34b931698da81@msnews.microsoft.com...
> Kevin Spencer <unclechut***@nothinks.com> wrote:
>> First of all, a null value is nothing. That is, it indicates that a
>> variable
>> or reference to data of a given type is unassigned, and therefore has no
>> value.
>
> I'd disagree with that - being unassigned is very different to being
> assigned the value null. Take:
>
> string x;
>
> string x = null;
>
> (Where x is a local variable.)
>
> In the first case, the variable is unassigned. In the second case, it
> is definitely assigned with a value of null, which is the value which
> doesn't refer to any object.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too
Author
5 Apr 2007 6:39 AM
Jon Skeet [C# MVP]
Kevin Spencer <unclechut***@nothinks.com> wrote:
> I'll have to take issue with you here, Jon. Null is not a value technically
> speaking, as a value is something. If you declare a string variable without
> initializing it, and test it for null, it will return true.

Not if it's a local variable - you'll get a compiler error saying it's
uninitialized. If it's a member variable, it will have the default
*value* of null.

The C# spec agrees with me (2nd edition, section 11.2):

<quote>
The special value null is compatible with all reference types and
indicates the absence of an instance.
</quote>

> While null
> doesn't have exactly the same technical meaning that it used to have back in
> the days of "simple" C programming, it still signifies nothing, and an
> unassigned variable is nothing. You can't make a distinction between nothing
> and nothing, and the compiler doesn't either.

You most certainly can. Try compiling the following:

using System;

class Program
{   
    static void Main(string[] args)
    {
        string x = null;
        Console.WriteLine (x);
    }
}

Now take out "= null" and you'll get:

Test.cs(8,28): error CS0165: Use of unassigned local variable 'x'

> There are situations in which the compiler will insist that you
> assign a null value to a variable, but those are "safety" checks, and
> it isn't consistent, as there are other times when it will not, and
> will test true for null with an unassigned variable.

Could you give an example where it will test true for null with a
variable which is unassigned in the terminology of the spec? Bear in
mind that instance variables of reference types are considered
"initially assigned variables".

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Author
5 Apr 2007 12:12 PM
Kevin Spencer
Hi Jon,

Well, it's a bit more complicated than that. If it's a parameter, for
example, the compiler doesn't complain at all. Example:

public boo StringIsNull(string s)
{
    return (s == null);
}

Also, note that I said "Null is not a value technically speaking." I
qualified my remark because it depends on what is meant by the term "value."
Of course, null must be represented by a "value" in memory, but it
represents the absence of a value. And as you pointed out, if a member is
declared and not initialized, it is "initialized" as null. But that holds
true for value types as well as reference types. So, what we're seeing here
is more a decision on the part of the designers of the compiler, rather than
a "physical" reality. They could just as easily have assumed a null value
for a local variable, but decided not to.

This is, of course, one of the problems with human language. It is subject
to interpretation. So, in fact, I don't think either of us is wrong about
what we are saying. One or both of us is just not trying hard enough to
understand the other!

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

Show quoteHide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MPG.207ea9efcff522ec98da86@msnews.microsoft.com...
> Kevin Spencer <unclechut***@nothinks.com> wrote:
>> I'll have to take issue with you here, Jon. Null is not a value
>> technically
>> speaking, as a value is something. If you declare a string variable
>> without
>> initializing it, and test it for null, it will return true.
>
> Not if it's a local variable - you'll get a compiler error saying it's
> uninitialized. If it's a member variable, it will have the default
> *value* of null.
>
> The C# spec agrees with me (2nd edition, section 11.2):
>
> <quote>
> The special value null is compatible with all reference types and
> indicates the absence of an instance.
> </quote>
>
>> While null
>> doesn't have exactly the same technical meaning that it used to have back
>> in
>> the days of "simple" C programming, it still signifies nothing, and an
>> unassigned variable is nothing. You can't make a distinction between
>> nothing
>> and nothing, and the compiler doesn't either.
>
> You most certainly can. Try compiling the following:
>
> using System;
>
> class Program
> {
>    static void Main(string[] args)
>    {
>        string x = null;
>        Console.WriteLine (x);
>    }
> }
>
> Now take out "= null" and you'll get:
>
> Test.cs(8,28): error CS0165: Use of unassigned local variable 'x'
>
>> There are situations in which the compiler will insist that you
>> assign a null value to a variable, but those are "safety" checks, and
>> it isn't consistent, as there are other times when it will not, and
>> will test true for null with an unassigned variable.
>
> Could you give an example where it will test true for null with a
> variable which is unassigned in the terminology of the spec? Bear in
> mind that instance variables of reference types are considered
> "initially assigned variables".
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
> If replying to the group, please do not mail me too
Author
5 Apr 2007 12:32 PM
Henning Krause [MVP - Exchange]
"Kevin Spencer" <unclechut***@nothinks.com> wrote in message
news:%23eHvgu3dHHA.4004@TK2MSFTNGP06.phx.gbl...
> Hi Jon,
>
> Well, it's a bit more complicated than that. If it's a parameter, for
> example, the compiler doesn't complain at all. Example:
>
> public boo StringIsNull(string s)
> {
>    return (s == null);
> }
>

But in this case, you always pass an assigned value to the method. It cannot
be unassigned  by definition. Its either null or has reference to something.

This differs from local variables.

Best regards,
Henning Krause
Author
5 Apr 2007 1:15 PM
Kevin Spencer
> But in this case, you always pass an assigned value to the method. It
> cannot be unassigned  by definition. Its either null or has reference to
> something.

It can be unassigned, if it is a member and not a local variable.

The bottom line (the one that matters, in other words) is that the ideas I
expressed in my original reply were correct, but the words I used to express
them were parsed incorrectly by people for whom the reply was not intended,
for wahtever reason. The OP has not asked for clarification regarding the
reply. I can only hope that this is because the OP understood what I was
saying.

In the end, it doesn't matter which end of the boiled egg one begins at, as
long as one eats the egg.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

Show quoteHide quote
"Henning Krause [MVP - Exchange]" <newsgroups_rem***@this.infinitec.de>
wrote in message news:e81TW63dHHA.4352@TK2MSFTNGP03.phx.gbl...
>
> "Kevin Spencer" <unclechut***@nothinks.com> wrote in message
> news:%23eHvgu3dHHA.4004@TK2MSFTNGP06.phx.gbl...
>> Hi Jon,
>>
>> Well, it's a bit more complicated than that. If it's a parameter, for
>> example, the compiler doesn't complain at all. Example:
>>
>> public boo StringIsNull(string s)
>> {
>>    return (s == null);
>> }
>>
>
> But in this case, you always pass an assigned value to the method. It
> cannot be unassigned  by definition. Its either null or has reference to
> something.
>
> This differs from local variables.
>
> Best regards,
> Henning Krause
>
Author
5 Apr 2007 1:20 PM
Henning Krause [MVP - Exchange]
If it's a member variable, it's assigned the null value at runtime. It's not
unassigned.

Best regards,
Henning Krause

Show quoteHide quote
"Kevin Spencer" <unclechut***@nothinks.com> wrote in message
news:uaPi1R4dHHA.984@TK2MSFTNGP04.phx.gbl...
>> But in this case, you always pass an assigned value to the method. It
>> cannot be unassigned  by definition. Its either null or has reference to
>> something.
>
> It can be unassigned, if it is a member and not a local variable.
>
> The bottom line (the one that matters, in other words) is that the ideas I
> expressed in my original reply were correct, but the words I used to
> express them were parsed incorrectly by people for whom the reply was not
> intended, for wahtever reason. The OP has not asked for clarification
> regarding the reply. I can only hope that this is because the OP
> understood what I was saying.
>
> In the end, it doesn't matter which end of the boiled egg one begins at,
> as long as one eats the egg.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
>
> Printing Components, Email Components,
> FTP Client Classes, Enhanced Data Controls, much more.
> DSI PrintManager, Miradyne Component Libraries:
> http://www.miradyne.net
>
> "Henning Krause [MVP - Exchange]" <newsgroups_rem***@this.infinitec.de>
> wrote in message news:e81TW63dHHA.4352@TK2MSFTNGP03.phx.gbl...
>>
>> "Kevin Spencer" <unclechut***@nothinks.com> wrote in message
>> news:%23eHvgu3dHHA.4004@TK2MSFTNGP06.phx.gbl...
>>> Hi Jon,
>>>
>>> Well, it's a bit more complicated than that. If it's a parameter, for
>>> example, the compiler doesn't complain at all. Example:
>>>
>>> public boo StringIsNull(string s)
>>> {
>>>    return (s == null);
>>> }
>>>
>>
>> But in this case, you always pass an assigned value to the method. It
>> cannot be unassigned  by definition. Its either null or has reference to
>> something.
>>
>> This differs from local variables.
>>
>> Best regards,
>> Henning Krause
>>
>
>
Author
5 Apr 2007 2:40 PM
Jon Skeet [C# MVP]
On Apr 5, 2:15 pm, "Kevin Spencer" <unclechut***@nothinks.com> wrote:
> > But in this case, you always pass an assigned value to the method. It
> > cannot be unassigned  by definition. Its either null or has reference to
> > something.
>
> It can be unassigned, if it is a member and not a local variable.

Not if it's a member of a reference type. In that case, it will be
definitely assigned according to the language specification.

If it's a member of a value type, the code should force you to
initialize that member before passing it as a parameter to a method.

> The bottom line (the one that matters, in other words) is that the ideas I
> expressed in my original reply were correct, but the words I used to express
> them were parsed incorrectly by people for whom the reply was not intended,
> for wahtever reason.

No, they were *not* correct in the only terms of reference which I
think can be said to be reasonably authoritative on such matters: the
C# language specification.

They may have been correct in some understanding of the terminology
which you have, but that could be said about anything. I could say
"string is a value type" and I'd be correct in the context of
terminology where value type actually meant what the C# spec deems a
reference type.

Many people say things like "objects are passed by reference by
default" - that's incorrect, even if they actually know what they mean
(the reference being passed by value). That's why it's crucial to have
a frame of reference such as the language specification, and in that
frame of reference your statement was fairly clearly incorrect.

<snip>

Jon
Author
5 Apr 2007 4:48 PM
Kevin Spencer
Jon,

Contentiousness is not my idea of time well spent. You win. I hope the OP
did.

--

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

Show quoteHide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:1175784006.345046.15670@q75g2000hsh.googlegroups.com...
> <snip>
>
> Jon
>
Author
5 Apr 2007 2:34 PM
Jon Skeet [C# MVP]
On Apr 5, 1:12 pm, "Kevin Spencer" <unclechut***@nothinks.com> wrote:
> Well, it's a bit more complicated than that. If it's a parameter, for
> example, the compiler doesn't complain at all. Example:
>
> public boo StringIsNull(string s)
> {
>     return (s == null);
>
> }

Yes, s is definitely assigned, according to the spec:

<quote>
The following categories of variables are classified as initially
assigned:
[...]
    * 6 Value parameters.
</quote>

In the above, s is a value parameter. So it is definitely assigned,
regardless of its value.

An "out" parameter, however, *isn't* definitely assigned at the start
of the method, so it would fail to compile - the variable would not
have a value which could be retrieved under the rules of the language.

> Also, note that I said "Null is not a value technically speaking." I
> qualified my remark because it depends on what is meant by the term "value."
> Of course, null must be represented by a "value" in memory, but it
> represents the absence of a value.

No, it represents the absence of an *instance* that value refers to.

> And as you pointed out, if a member is
> declared and not initialized, it is "initialized" as null. But that holds
> true for value types as well as reference types. So, what we're seeing here
> is more a decision on the part of the designers of the compiler, rather than
> a "physical" reality.

I'm talking on the language level more than anything else - where null
is clearly defined to be a value which doesn't refer to any instance.

> They could just as easily have assumed a null value
> for a local variable, but decided not to.

They could have done - but only if they'd made sure that whatever the
compiler was targetting would give local variables the value "null" to
start with. (IIRC, this is true for the CLI.)

> This is, of course, one of the problems with human language. It is subject
> to interpretation. So, in fact, I don't think either of us is wrong about
> what we are saying. One or both of us is just not trying hard enough to
> understand the other!

Well, that's one of the purposes of specifications - to define what
terms mean as far as possible. In this case, the C# spec defines both
"null" and "unassigned variable" - and they are *not* the same thing
at all.

Jon
Author
5 Apr 2007 4:50 PM
Kevin Spencer
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:1175783655.577711.161740@o5g2000hsb.googlegroups.com...
> Well, that's one of the purposes of specifications - to define what
> terms mean as far as possible. In this case, the C# spec defines both
> "null" and "unassigned variable" - and they are *not* the same thing
> at all.
>
> Jon
>

Hm, remind me not to discuss the Bible with you at any time in the future.

--
;-),

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net
Author
5 Apr 2007 7:11 AM
Jon Skeet [C# MVP]
On Apr 4, 10:35 pm, "Kevin Spencer" <unclechut***@nothinks.com> wrote:
> I'll have to take issue with you here, Jon. Null is not a value technically
> speaking, as a value is something. If you declare a string variable without
> initializing it, and test it for null, it will return true. While null
> doesn't have exactly the same technical meaning that it used to have back in
> the days of "simple" C programming, it still signifies nothing, and an
> unassigned variable is nothing. You can't make a distinction between nothing
> and nothing, and the compiler doesn't either. There are situations in which
> the compiler will insist that you assign a null value to a variable, but
> those are "safety" checks, and it isn't consistent, as there are other times
> when it will not, and will test true for null with an unassigned variable.

Just a few follow-up points I thought of on the way to work:

1) Do you believe that 0 is a real value for an int type? Because
precisely the argument you're using to say that null is the equivalent
of an unassigned value (for reference types) apply to 0 for int
variables - it just happens to be the default value.

2) How do you get around the fact that you can assign the value null
to a variable? Does that make the variable become "unassigned" in your
view? It certainly doesn't in the terminology of any spec I've ever
seen.

3) How about parameter passing - you pass a *value*, whatever that
value is - including null. If null weren't considered a value, the
spec would have to explicitly make mention of it every time the value
of *any* expression were considered.

(Btw, the CLI spec refers to null as a special value too.)

Do you have any evidence from either the CLI spec or the C# spec that
null is *not* a value? "Not a value technically" suggests you've got
some technical source for this statement - could you provide it? I
think the evidence is pretty strong from what I've posted that it
technically *is* a value.

(The above is all talking about reference types. In the context of
nullable types, when you assign the value null in C# to, say, a
Nullable<int> variable, you're still assigning a value, but its
HasValue property will be false.)

Jon
Author
5 Apr 2007 1:09 PM
Kevin Spencer
> 1) Do you believe that 0 is a real value for an int type? Because
> precisely the argument you're using to say that null is the equivalent
> of an unassigned value (for reference types) apply to 0 for int
> variables - it just happens to be the default value.

Back when I started using C, Kernigan and Ritchie C, that is, which is the
"purest" form, when you declared an integer without assigning it, it didn't
have a value of 0. It had the value of whatever was in the memory location
that the compiler assigned it to. This was because C was not initially
designed to "fix things up" for inexperienced developers.

The fact that the C# compiler assigns a default value to an integer is
something built into the compiler. So, again, we're talking English
semantics here rather than reality. In reality "null" signifies "nothing."
Now, a computer cannot represent nothing without using some number, so 0 (\0
in C) has traditionally been the "value" used to signify nothing, which is
the source of the confusion. Take a look at the dictionary definition of
"null" - http://dictionary.reference.com/search?q=null.

With the advent of higher-level programming languages, more abstraction away
from numbers was added to the mix. For example, in C, 0 is false, and
*anything else* is true. In C, you can write:

while (a + b) { ... }

Logically, this makes perfect sense. Since true is not false, and false is
not true, if 0 is false, what is 2? Since 2 is not 0, it is true. However,
the abstraction introduced by these higher-level languages also muddied the
water. These languages are all compiled to machine language, and therefore
represent mathematical operations. The abstraction proves to be useful, but
at a price, which is confusion. Today, false is not treated as a number by
the developer, and the concepts of true and false have been abstracted to a
higher level which ultimately must be processed numerically by the computer.

The same holds true for "null." The current abstraction level of computing
languages, C# in this discussion, can cause confusion when being talked
about using human language, as the abstractions approximate human ideas. So,
again, we're just having a semantic argument here, which I'm not sure is
useful.

So, I will stand behind my statement that null signifies nothing, which
means that it signifies the absense of a value. One can not signify nothing
with nothing. It must be represented by something. Hence, the confusion.

But, to put it more colloquially, how about trying to understand what I'm
saying, rather than mincing my words? We all have different ways of talking
about things. But it is not the words we use that matter, as much as the
ideas they represent. Human language is not a programming language like C#,
where every token always means exactly the same thing, and there is no room
for interpretation. On the contrary, human language is all about
interpretation, nuance, and gist.

I only hope the OP isn't entirely befuddled by this point! ;-)

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

Show quoteHide quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:1175757089.974641.34620@q75g2000hsh.googlegroups.com...
> On Apr 4, 10:35 pm, "Kevin Spencer" <unclechut***@nothinks.com> wrote:
>> I'll have to take issue with you here, Jon. Null is not a value
>> technically
>> speaking, as a value is something. If you declare a string variable
>> without
>> initializing it, and test it for null, it will return true. While null
>> doesn't have exactly the same technical meaning that it used to have back
>> in
>> the days of "simple" C programming, it still signifies nothing, and an
>> unassigned variable is nothing. You can't make a distinction between
>> nothing
>> and nothing, and the compiler doesn't either. There are situations in
>> which
>> the compiler will insist that you assign a null value to a variable, but
>> those are "safety" checks, and it isn't consistent, as there are other
>> times
>> when it will not, and will test true for null with an unassigned
>> variable.
>
> Just a few follow-up points I thought of on the way to work:
>
> 1) Do you believe that 0 is a real value for an int type? Because
> precisely the argument you're using to say that null is the equivalent
> of an unassigned value (for reference types) apply to 0 for int
> variables - it just happens to be the default value.
>
> 2) How do you get around the fact that you can assign the value null
> to a variable? Does that make the variable become "unassigned" in your
> view? It certainly doesn't in the terminology of any spec I've ever
> seen.
>
> 3) How about parameter passing - you pass a *value*, whatever that
> value is - including null. If null weren't considered a value, the
> spec would have to explicitly make mention of it every time the value
> of *any* expression were considered.
>
> (Btw, the CLI spec refers to null as a special value too.)
>
> Do you have any evidence from either the CLI spec or the C# spec that
> null is *not* a value? "Not a value technically" suggests you've got
> some technical source for this statement - could you provide it? I
> think the evidence is pretty strong from what I've posted that it
> technically *is* a value.
>
> (The above is all talking about reference types. In the context of
> nullable types, when you assign the value null in C# to, say, a
> Nullable<int> variable, you're still assigning a value, but its
> HasValue property will be false.)
>
> Jon
>
Author
5 Apr 2007 2:51 PM
Jon Skeet [C# MVP]
Show quote Hide quote
On Apr 5, 2:09 pm, "Kevin Spencer" <unclechut***@nothinks.com> wrote:
> > 1) Do you believe that 0 is a real value for an int type? Because
> > precisely the argument you're using to say that null is the equivalent
> > of an unassigned value (for reference types) apply to 0 for int
> > variables - it just happens to be the default value.
>
> Back when I started using C, Kernigan and Ritchie C, that is, which is the
> "purest" form, when you declared an integer without assigning it, it didn't
> have a value of 0. It had the value of whatever was in the memory location
> that the compiler assigned it to. This was because C was not initially
> designed to "fix things up" for inexperienced developers.
>
> The fact that the C# compiler assigns a default value to an integer is
> something built into the compiler.

Well, it's built into the language. Whether the compiler needs to do
anything to achieve that depends on the platform it's targetting. (For
the CLI, I don't believe it needs to do anything.)

> So, again, we're talking English
> semantics here rather than reality. In reality "null" signifies "nothing."

No, in reality "null"'s significance varies depending on the context.
The context here is either C# or the CLI, where it is "the special
value indicating an absence of an instance".

<snip>

> The same holds true for "null." The current abstraction level of computing
> languages, C# in this discussion, can cause confusion when being talked
> about using human language, as the abstractions approximate human ideas. So,
> again, we're just having a semantic argument here, which I'm not sure is
> useful.

I think the reason we're having an argument is because you're ignoring
the terminology used by the C# language specification. One of the
points of specifications is to remove the confusion and ambiguity
which arises out of terms not being well defined.

"null" is well defined in the spec, as is the concept of a variable
being definitely assigned. I've been using those terms as per the
spec, which anyone can read. You've been using them according to your
own internal understanding of them, as far as I can see, which no-one
else can read.

> So, I will stand behind my statement that null signifies nothing, which
> means that it signifies the absense of a value. One can not signify nothing
> with nothing. It must be represented by something. Hence, the confusion.

No, the confusion was mostly when you started saying that a variable
with the value "null" was the same as an unassigned variable, and that
"null" isn't a value. Those statements are clearly at odds with the C#
language spec.

> But, to put it more colloquially, how about trying to understand what I'm
> saying, rather than mincing my words?

Okay, to put it bluntly back: why don't you start using terms in the
way the spec defines them, instead of in a way which isn't defined
anywhere? How do you expect people to understand you when you use
words/terms in a different way than the accepted/specified way?

When you talk about a variable with a null value being the same as a
variable which isn't assigned a value, it's reasonable for the reader
to think you might be using those terms in the accepted (specified)
way. According to that specification, your statements are incorrect,
plain and simple.

> We all have different ways of talking
> about things. But it is not the words we use that matter, as much as the
> ideas they represent. Human language is not a programming language like C#,
> where every token always means exactly the same thing, and there is no room
> for interpretation. On the contrary, human language is all about
> interpretation, nuance, and gist.

Hence the need for a specification, and hence the desirability of
everyone using terms in the way that the specification (whatever
specification is relevant in the context) defines.

Jon
Author
4 Apr 2007 5:05 PM
Jon Skeet [C# MVP]
AVL <A**@discussions.microsoft.com> wrote:
> i'm a new bie to c#.net 2.0....
> i've come across a new feature by name nullable types...need some info on it
>
> what is actually a null value...
> what exactly is advantage we get by specifying a value type as a null value...

See http://pobox.com/~skeet/csharp/csharp2/nullable.html

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

Bookmark and Share