Empty VS null array?

[Kagamin]

On Monday, 21 October 2013 at 10:33:01 UTC, Regan Heath wrote:
> null strings are no different to null class references, they're 
> not a special case.

True. That's an implementation detail which has no meaning for 
business logic. When implementation deviates from business logic, 
one ends up fixing the implementation details everywhere in order 
to implement business logic. That's why string.IsNullOrEmpty is 
used.

> People seem to have this odd idea that null is somehow an 
> invalid state for a string /reference/ (c# strings are 
> reference types), it's not.

That's the very problem: null and empty are valid states and must 
be treated equally as "no data", but they can't for purely 
technical reasons.

> People also seem to elevate empty strings to some sort of 
> special status, that's like saying 0 has some special status 
> for int - it doesn't it's just one of a number of possible 
> values.
>
> In fact, int having no null like state is a "problem" causing 
> solutions like boxing to elevate the value type to a reference 
> in order to allow a null state for int.

You want to check ints for null everywhere too?

> Yet, in D we've decided to inconsistently remove that 
> functionality from string for no gain.  If string could not 
> actually be null then we'd gain something from the limitation, 
> instead we lose functionality and gain nothing - you still have 
> to check your strings for null in D.

Huh? Null slices work just like empty ones - that's why this 
topic was started in the first place. One doesn't have to check 
slices for nulls, only for length.

If you want clear nullable semantics, you have Nullable, it works 
for everything, including strings and ints. You would want this 
feature only in rare cases, so it doesn't make sense to make it 
default, or it will be a nuisance.

>> both of them are just "no data", so you end up typing 
>> if(string.IsNullOrEmpty(mystr)) every time everywhere.
>
> I only have to code like this when I use 3rd party code which 
> has conflated empty and null.  In my code when it's null it 
> means not specified, and empty is just one type of value - for 
> which I do no special handling.

Equivalence between null and empty is a business logic's 
requirement, that's why it's done.

>> And, yeah, only one small feature in this big mess ever needs 
>> to differentiate between null and empty.
>
> Untrue, null allows many alternate and IMO more direct/obvious 
> designs.

The need for those designs is rare and trivially implementable 
for all value types.

>> I found this one case trivially implementable, but nulls still 
>> plague all remaining code.
>
> Which one case?  The readline() one below?

No, it was an authentication system in third-party code for one 
special case. I also had to specify this null value in app.config 
- guess how, explicitly specify, not substitute missing parameter 
with a default.

Another possibility for readline is to return a tuple
{bool eof, string line(non-null)} - this way you have easy check 
for eof and don't have to check for null when you don't need it.

> I use this all the time:
> http://msdn.microsoft.com/en-us/library/system.io.streamreader.readline.aspx
>
> It has never caused me any issues.  It explicitly states that 
> null is a possible output, and so I check for it - doing 
> anything less is simply bad programming.
>
>> It works if you read one line per loop cycle, but if you read 
>> several lines and assume they're not null (some multiline data 
>> format),
>
> There is your problem, never "assume" - the documentation is 
> very clear on the issue.
>
>> you're screwed or your code becomes littered with null checks, 
>> but who accounts for all alternative scenarios from the start?
>
> Me, and IMO any competent programmer.  It is misguided to think 
> you can ignore valid states, null is a valid state in C, C++, 
> C#, and D.. You should be thinking about and handling it.

Here null is a valid state for readline, not for the caller: if 
the caller parses a multiline data format, unexpected end of file 
is an invalid state.

And what do you gain by littering your code with those null 
checks? Just making runtime happy and adding noise to the code? 
You could use that time to improve the code or add features or 
even relax. It's exactly nullable strings, which gain you only a 
time waste.

> You don't have to check for it on every access to the variable, 
> but you do need to check for it once where the variable is 
> assigned, or passed (in private functions you can skip this).  
> From that point onward you can assume non-null, valid, job done.

You just said "never assume". The assumption may fail, because 
the string type is still nullable, compiler doesn't save you 
here, this sucks. And in order to check for everything everywhere 
on a level near that of the compiler, you must be not just 
competent, but perfect.

>> I believe there's no problem domain, which would like to 
>> differentiate between null and empty string instead of 
>> treating them as "no data".
>
> null means not specified, non existent, was not there.
> empty means, present but set to empty/blank.
>
> Databases have this distinction for a reason.

Oracle makes no distinction between null and empty string. For a 
reason?
A database is an implementation detail of a data storage, it 
doesn't implement business logic, it only provides features, 
which can be used with more or less success to implement business 
logic. Ever heard of advantages of OO databases over relational 
ones? That's an illustration of technical details, which don't 
precisely map to business logic.

> If you get input from a user a field called "foo" may be:
>  - not specified
>  - specified
>
> and if specified, may be:
>  - empty
>  - not empty

If the user doesn't fill a text box, it's both empty and not 
specified - there's just no difference. And it doesn't matter how 
you store it in the database - as null or as empty string - both 
are presented in the same way. Heck, we use these optional text 
boxes everywhere - can you tell if their content is empty or not 
specified?

And what if the value is required? Would you accept an empty 
value? And if your database treats empty string as not null, 
would you allow to register a user with an empty login name? And 
how to express this constraint in the database? In SQL "not null" 
means "required value", but it's not equivalent to the business 
logic'a notion of a required value. I wouldn't be surprised if 
Oracle did that in order to reject empty strings in not null 
fields.

Let's consider a process of specifying user's data. What text 
fields do we have?
1. Login. No difference between null and empty - both invalid - 
"no data", must enter something.
2. First name. No difference between null and empty - both are 
"no data" and are presented as empty text box.
3. Middle name. ditto.
4. Last name. ditto.
5. Country. ditto.
6. State. ditto.
7. City. ditto.
8. Address. ditto.
9. Building. ditto.
10. Flat. ditto.
11. Zip code. ditto.
12. Phone. ditto.
13. Fax. ditto.
14. E-mail. ditto.
15. Site. ditto.
16. Passport number. ditto.
17. Birth place. ditto.
18. Comment. Hell! Comment!
See? Not a single field in the list requires distinction between 
null and empty. And slices don't differentiate between them. Just 
as planned.

> If we have null, lets use it, if we want to remove null the 
> lets remove it, but can we get out of this horrid middle ground 
> please.

*sigh* people just don't buy the KISS principle...