> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"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

"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

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

"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

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

"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

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

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

>
> Pete

:

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

"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

"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

"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

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

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

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:1175784006.345046.15670@q75g2000hsh.googlegroups.com...
> <snip>
>
> Jon
>

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

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.