C# Nullable types

On Apr 5, 1:12 pm, "Kevin Spencer" <unclechut...@nothinks.com> wrote:
> Well, it's a bit more complicated than that. If it's a parameter, for
> example, the compiler doesn't complain at all. Example:
>
> public boo StringIsNull(string s)
> {
> return (s == null);
>
> }

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

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

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

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

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

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

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

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

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

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

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

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

Jon

On Apr 5, 2:15 pm, "Kevin Spencer" <unclechut...@nothinks.com> wrote:
> > But in this case, you always pass an assigned value to the method. It
> > cannot be unassigned by definition. Its either null or has reference to
> > something.
>
> It can be unassigned, if it is a member and not a local variable.

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

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

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

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

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

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

<snip>

Jon

On Apr 5, 2:19 pm, "Scott M." <s...@nospam.nospam> wrote:
> Hmmm, again, to my knowledge the concepts of "undefined", "unknown"," not
> applicable" have never been identified with "null" in SQL or anywhere else.
> When I mark a filed in SQL as "nullable", I am not doing it because I don't
> know what value the user may want to put into the field. On the contrary, I
> do it because I'm letting the user not put any value at all into the field.
>
> Again "undefined", "unknown"," not applicable" does not equal "null". I
> think this is super-important to be clear on, because "null" has a special
> purpose and meaning and the minute you try to attach a meaning that is
> something similiar, but not the same, to it, you confuse the issue and make
> it more complicated than it need be.

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

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

Jon

On Apr 5, 2:09 pm, "Kevin Spencer" <unclechut...@nothinks.com> wrote:
> > 1) Do you believe that 0 is a real value for an int type? Because
> > precisely the argument you're using to say that null is the equivalent
> > of an unassigned value (for reference types) apply to 0 for int
> > variables - it just happens to be the default value.
>
> Back when I started using C, Kernigan and Ritchie C, that is, which is the
> "purest" form, when you declared an integer without assigning it, it didn't
> have a value of 0. It had the value of whatever was in the memory location
> that the compiler assigned it to. This was because C was not initially
> designed to "fix things up" for inexperienced developers.
>
> The fact that the C# compiler assigns a default value to an integer is
> something built into the compiler.

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

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

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

<snip>

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

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

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

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

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

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

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

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

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

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

Jon

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.1244@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.284@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.4636@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" <AVL@discussions.microsoft.com> a écrit dans le message de
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

On Wed, 04 Apr 2007 12:20:48 -0700, Scott M. <s-mar@nospam.nospam> wrote:

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

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

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

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

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

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

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

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

Pete

I will just end with how the SQL Server doc explains this.

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

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

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

--
Patrice

"Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
OMPOZW5dHHA.4308@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.1244@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.284@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.4636@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" <AVL@discussions.microsoft.com> a écrit dans le message de
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

> 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

"Patrice" <http://www.chez.com/scribe/> wrote in message
news:edMkW65dHHA.4032@TK2MSFTNGP02.phx.gbl...
>I will just end with how the SQL Server doc explains this.
>
> http://msdn2.microsoft.com/en-us/library/ms191504.aspx :
> "Null values generally indicate data that is unknown, not applicable, or
> that the data will be added later."
>
> I'm not sure what is the point you don't like in this definition that
> looks quite close to mine but it really looks like that understanding each
> other on this topic is out of reach.

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

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

You too!


>
> --
> Patrice
>
> "Scott M." <s-mar@nospam.nospam> a écrit dans le message de news:
> OMPOZW5dHHA.4308@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.1244@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.284@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.4636@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" <AVL@discussions.microsoft.com> a écrit dans le message de
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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

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

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

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