Null Strings Treated As Empty Strings

Archives Forums/BlitzMax Bug Reports/Null Strings Treated As Empty Strings

N	(Posted 2009) [#1]

This probably isn't a proper bug so much as it's... I guess an inconsistency.

Basically:

If "" = Null Then
	Print "This"
EndIf

Local s:String = ""
If s = Null Then
	Print "should"
EndIf

If s = "" Then
	Print "not"
EndIf

s = Null
If s.Length = 0 Then
	Print "work"
EndIf

I noticed this sort of behavior was causing some code I started writing to explode with exceptions when it tests for Null strings being passed around. This is mostly because I make a distinction between Null and an empty string. An empty string doesn't have content, but it's an instance of a string. Null is not an instance- or, in the case of BMax, it's a really special instance, but it's not a string and it doesn't have a class. Apparently empty strings are special instances too, but an empty string shouldn't equate to Null, ever, as far as I'm concerned.

A brief example. This doesn't compile:

If Null.Length = 0 Then
	Print "And this is why"
EndIf

You know why? Because Null isn't a string!

But this does.

If String(Null).Length = 0 Then
	Print "And this is why"
EndIf

So apparently Null is a string, you just have to downcast it.

So, I'm putting this up as a bug because this really should not work.

Otus	(Posted 2009) [#2]

That's how it works, and I think should work. A Null String is an empty String. Checking for length=0 is the same as checking =Null. Casting any non-string object to String gives you an empty String.

GfK	(Posted 2009) [#3]

I'm with Nilium on this one. Null isn't anything. Its not an empty string, its not zero. Its Null.

N	(Posted 2009) [#4]

That's how it works, and I think should work. A Null String is an empty String. Checking for length=0 is the same as checking =Null. Casting any non-string object to String gives you an empty String.

The way I see it is this: Null is nothing - it cannot be an accessible instance of something. An empty string is an instance of a string with no contents - it might be empty, but it's still an instance. It has instance variables and it has a buffer, albeit an empty buffer (and possibly NULL in that case, be that as it may, but it's not a Null string, it's just an empty string).

A variable can be null when it doesn't point to an instance of an object. Null should be nothing, inaccessible - accessing it should produce an exception at a minimum, and probably take down your application at the worst. Equating Null to an empty string strikes me as ambiguity that isn't needed and only makes it more difficult to determine the value of something.

Otus	(Posted 2009) [#5]

Yeah, well, here's what the docs say:

Null returns 0, an empty string, an empty array, the null object or a pointer to 0 depending on context.

marksibly

(Posted 2009) [#6]

Hi,

> Null returns 0, an empty string, an empty array, the null object or a pointer to 0 depending on context.

That about says it all...

In the case of strings especially, I don't like the idea of an exception causing 'nothing' string - this largely negates the usefulness of strings being immutable, 'value style' objects.

> Null is nothing

Then what can you do with it? Can you assign it to anything? Compare it with anything? What is it's type?

The idea of 'nothing' makes a certain amount of sense in an interpreted language like, say, Lua, where variables may or may not exist (if they don't exist, then they can truly said to be 'nothing' or 'nil' in Lua speak - assigning 'nil' to a var in Lua effectively deletes it) but less in a compiled language where variables definitely do or do not exist.