Mozilla have lost their mind - Part 2
-
Hey Mason, I apologize for only having skimmed through the walls of text above, but did you ever get to explain why you're opposed to everything-as-an-object?
For the record, my opinion is that all variables should be reference types, everything other than null should be an object, and variable types should not be nullable unless explicitly declared as such.
And comparisons between objects of different types should fail (which means empty string is different from null). No comparing apples and oranges unless you explicitly coerce an apple to an orange or the other way around.
BTW, I won't be around today, so I'm just dropping this subject on your collective lap to fuel further discussion if you're into it.
@Sutherlands said:
No, his point was that we never care, which is a very important difference. If you look back over the thread, you will never see me saying that we care all the time, or even that it's an important distinction most of the time, simply that it's an important distinction some of the time, which means it's an important distinction for a language to have. The same with having a short-circuiting operator and a separate non-short-circuiting operator. He was saying that you should NEVER need the difference, because he hasn't encountered it, whereas I was saying that (while true in most cases) that doesn't invalidate the feature.
QFT.
-
@blakeyrat said:
@boomzilla said:
How do you tell the difference between a text box that's empty because the question wasn't asked and one that's empty because the real information is that there is no information?
That would be the point of using NULL.
@boomzilla said:
What's the UI convention? These are real questions.
The user clicks through to their Profile page (or whatever it's called) and fills in fields. Alternatively, if it's something like a shipping address, the customer fills it in as part of the checkout funnel. Do you not use e-commerce in any way whatsoever?
@boomzilla said:I've never seen an app that appeared to do this.
I've never seen a CRM application NOT do this. Log in to Amazon.com. Or JC Penney. Or Live.com. Or Facebook. Or Twitter. Keep track of how much information you need to create an account, then look at how much optional information you can fill-in on top of that.@boomzilla said:
but stuff like home phone is probably right there in the main form or whatever.
It used to be, but people have learned (some companies better than others) that the fewer questions you ask initially, the more signups you get.OK, so when they click through, and leave a field blank, what does that mean? Why do you care if it's null or an empty string, and how do you know the difference based on the way the user submits the information?
@blakeyrat said:
@boomzilla said:
So then, when the next customer service drone gets a call from this person, looks up the account, how can he tell that he shouldn't ask about this stuff, because it's already been determined that we've asked this question and the customer doesn't want to answer.
Any information your phone service needs to ask would have to be a required field.
OK, so the null vs empty string doesn't really matter? Or, if it does, how does the user of the application indicate this?
@blakeyrat said:
If you say so. Like I said above, though, I've never seen a CRM not work that way. (Except ancient, creaky ones from 1997 that like have 2 mile long sign-up forms. Some of those are still around.)
The point isn't about how much you cram on the signup form. From everything you've given here, there's no real advantage to being able to distinguish between an empty string and a null. Thanks for helping to prove the point.
-
OK, having ploughed through all of this, can someone explain something to me: do the computers you're talking about have some strange physical properties that let them have three states - on/off/null? If not, how would a null string actually be represented in terms of a series of bits? Is there any effective difference between defining a null string at the language level, or merely at the programmatic level where the text <NOT SET YET> (for example) is treated as a null?
-
@intertravel said:
OK, having ploughed through all of this, can someone explain something to me: do the computers you're talking about have some strange physical properties that let them have three states - on/off/null?
Null would represent a non-existant computer. Your computer isn't on, it isn't off, it simply isn't there to begin with.
-
@RHuckster said:
Null would represent a non-existant computer. Your computer isn't on, it isn't off, it simply isn't there to begin with.
You have to be careful to avoid confusing that with FILE_NOT_FOUND, however.
-
@intertravel said:
OK, having ploughed through all of this, can someone explain something to me: do the computers you're talking about have some strange physical properties that let them have three states - on/off/null? If not, how would a null string actually be represented in terms of a series of bits?
I'm not a hardware expert, but I believe 1s and 0s in computers aren't represented by on and off, but by different voltages. So there's high voltage, low voltage and zero voltage. But that's irrelevant to the question.@intertravel said:
how would a null string actually be represented in terms of a series of bits? Is there any effective difference between defining a null string at the language level, or merely at the programmatic level where the text (for example) is treated as a null?
I'm not sure I understand your second question, but the answer to your first question is rather obvious if you know C, or just pointers. A variable containing a null string is a pointer to position zero in memory (which is invalid), while an empty string is a pointer to somewhere valid in memory where we are storing a string of length zero.Or, in a higher level language, your variable containing a null string is a pointer to a valid data structure somewhere in memory, but the metadata for this data structure says (somehow) that this is a string, yes, but its value is null.
-
-
-
@dhromed said:
@blakeyrat said:
Is that a Pokemon? I don't speak your hep lingo.
You are CG.
Yeah... I'm just going to nod and back away very... sloooowly...
-
@Zecc said:
A variable containing a null string is a pointer to position zero in memory (which is invalid), while an empty string is a pointer to somewhere valid in memory where we are storing a string of length zero.
Yeah, and in terms of what would actually be contained in memory - a string of bits, no?
-
@intertravel said:
@Zecc said:
Because I feel like you're really asking...A variable containing a null string is a pointer to position zero in memory (which is invalid), while an empty string is a pointer to somewhere valid in memory where we are storing a string of length zero.
Yeah, and in terms of what would actually be contained in memory - a string of bits, no?Pointer to 0x00000000 = Null string
Pointer to 0x1c3e99f1, contained at that memory is a string of length 0 = empty string
Pointer to 0xee213411, contained at that memory is a string of length 10 = string
-
Today's main article demonstrates another reason why making a distinction between null and empty strings is a bad idea...
-
@Mason Wheeler said:
Today's main article demonstrates another reason why proper data entry is important
FTFY
-
@Sutherlands said:
@Mason Wheeler said:
Today's main article demonstrates another reason why proper data entry is important
FTFYDoes that look to you like the data was not entered correctly? Looks to me like they've got the right data; they just didn't handle it properly. This error would not have been possible in a language that does not make a distinction between a null string and an empty string.
-
@Mason Wheeler said:
Today's main article demonstrates another reason why making a distinction between null and empty strings is a bad idea...
What does the $94444.44 WTF demonstrate? That the language shouldn't allow "obvious" large differences between a regular price and a sales price?
The display of null in the FP article only demonstrates that the development team didn't do enough testing and let that bug pass by. Just like the development team in Monster didn't do enough testing in distance measurements, Price Spider didn't do enough testing on determining possible errors in price fluctuations (unless, of course, we end up in a period of drastic price deflation, in which case we have much bigger problems) and Intellisurvey didn't do enough testing in adding numbers (which, ironically *could* be the result of the user leaving the field empty instead of specifying a "zero" value, but that's just speculation)
Just because something in the language or the database allows "null" to be displayed in the output doesn't make it a "bad idea." Using your logic because I encounter an uncaught divide-by-zero error something should change in the fundamentals of programming to "prevent" developers from ever making that mistake.
-
@Sutherlands said:
Mind you, using 0x00000000 for the null pointer is only convention (because it sounds right, so to speak). Any value that could not be confused with a valid pointer could be used. In fact, C++0 introduces a new keyword@intertravel said:
@Zecc said:
Because I feel like you're really asking...A variable containing a null string is a pointer to position zero in memory (which is invalid), while an empty string is a pointer to somewhere valid in memory where we are storing a string of length zero.
Yeah, and in terms of what would actually be contained in memory - a string of bits, no?Pointer to 0x00000000 = Null string
Pointer to 0x1c3e99f1, contained at that memory is a string of length 0 = empty string
Pointer to 0xee213411, contained at that memory is a string of length 10 = string
nullptrto be used as the value for the null pointer instead of the usual#define NULL ((void*)0).
-
@Zecc said:
Mind you, using 0x00000000 for the null pointer is only convention (because it sounds right, so to speak). Any value that could not be confused with a valid pointer could be used. In fact, C++0 introduces a new keyword
nullptrto be used as the value for the null pointer instead of the usual#define NULL ((void*)0).It's C history time!
What's really entertaining is that in C when you have something like
int *pointer = 0;the contents of the memory address which identifies 'pointer' are not guaranteed to be 0. The C specification states that the internal representation of a pointer assigned the value 0 is implementation dependent, but the compiler should always treat source code involving pointers and the value 0 as if they compare to that special value. The reason is because on some hardware platforms, 0 is a valid address and something like, say, ~0 was the only guaranteed-invalid address.
I'm curious as to why people think a keyword like
nullptris an improvement over the literal 0; I never even use the NULL macro because I find it cumbersome. But then again, I'm weird.
-
@too_many_usernames said:
I'm curious as to why people think a keyword like
nullptris an improvement over the literal 0.
My guess would be something to do with type checking. No doubt there are people seriously disturbed that they can compare a pointer an an integer.
-
@boomzilla said:
My guess would be something to do with type checking. No doubt there are people seriously disturbed that they can compare a pointer an an integer.
I guess I never thought of that - I don't consider '0' to be an integer. Or, more precisely, I don't consider it to be just an integer; it depends on context. (Besides, you can't actually compare a pointer to any old integer; you get warnings for comparison or assignment of any integer other than 0.)
To reinforce my point:
People seem to have no problem with concepts like operator overloading for things that make no sense, like
String string = "strings " + "obey " + "math?"Strings are most clearly not numbers, but the idea of overloading the + operator to mean concatenation is "common practice" even though it troubles me because "addition doesn't work that way". But if that type of overloading is acceptable, why is having 0 be a special character whose meaning depends on the context so taboo?
-
The nullptr keyword was added for clarity when calling overloaded functions and the like. In C++ unlike C null has to be defined as just 0. So when calling an overloaded function that either took some sort of pointer or a int with NULL, the int version would have been called.
-
@too_many_usernames said:
I had no idea. Anyway, I'm about as weird as you, since I always use 0 too (if left to my own devise). Maybe I'm paranoid and fear some header I include may redefine NULL, I don't know.the contents of the memory address which identifies 'pointer' are not guaranteed to be 0. The C specification states that the internal representation of a pointer assigned the value 0 is implementation dependent, but the compiler should always treat source code involving pointers and the value 0 as if they compare to that special value. The reason is because on some hardware platforms, 0 is a valid address and something like, say, ~0 was the only guaranteed-invalid address.
I'm curious as to why people think a keyword like
nullptris an improvement over the literal 0; I never even use the NULL macro because I find it cumbersome. But then again, I'm weird.As for boomzilla's guess about type-checking, Wikipedia seems to confirm. In particular they mention something about the ambiguity of calling
foo(NULL);when there is afoo(int i)overload.
-
This thread has some of the funniest material I've seen on this site. A++ to all trolls, errrr parties involved
-
@too_many_usernames said:
Relevant FAQ:5.5: How should NULL be defined on a machine which uses a nonzero bit pattern as the internal representation of a null pointer?@too_many_usernames said:It's C history time!
What's really entertaining is that in C when you have something like
int *pointer = 0;the contents of the memory address which identifies 'pointer' are not guaranteed to be 0.
I'm curious as to why people think a keyword like
5.4:nullptris an improvement over the literal 0; I never even use the NULL macro because I find it cumbersome. But then again, I'm weird.As a matter of style, many programmers prefer not to have unadorned 0's scattered through their programs, some representing numbers and some representing pointers.
