Nullable String/Arrays

Monkey Forums/Monkey Programming/Nullable String/Arrays

Samah(Posted 2012) [#1]
Mark,
Given that Strings and arrays are arguably "non-primitive", how hard would it be to make them nullable?

Edit: On second thought, this opens up new realms of "if null or empty string" which would be somewhat dangerous for new programmers. I'll just have to live with an extra indicator flag.


AdamRedwoods(Posted 2012) [#2]
Could you just extend String (NString Extends String)?


Samah(Posted 2012) [#3]
I'd have to "wrap" String, because I'm pretty sure you can't extend it. What I've been doing is using the StringObject class, but that has huge overheads.


marksibly(Posted 2012) [#4]
Hi,

I'm not keen on the idea personally as I *like* the fact that strings/arrays are 'values' and can't ever be null, basically because it means you get to avoid a ton of <>Null sanity checks and a bunch of null vs empty string confusion.

Also, null strings complicate bool conversion - eg: what does If Str... mean? Is it 'Str<>Null'? Or 'Str<>Null And str.Length<>0' or, god forbid, 'str.Length<>0' (crash!). However it's done (or even if implicit string-to-bool is removed altogether) it's gonna break code.

But...why exactly do you want this feature?

In general, it would help enormously if people could provide some context or 'use cases' when making language feature requests like this. Just asking 'can you add xyz to the language' doesn't give me much to go on, unless perhaps it's something I've been thinking of adding myself.

As an alternative, how about something like:

Global NullString:=String.FromChar(-1) 'or some other BAD unicode char.
...
Local str:=NullString
...
If str=NullString


[edit]
Just saw your edit!
[/edit]


Samah(Posted 2012) [#5]
I was hoping to be able to use a single nullable variant type basically, because at the moment I'm using Object and assigning boxed primitives.

On another note, could we at least get byref array comparison? Surely it shouldn't be too hard...

[monkeycode]Local a:Int[] = [1,2,3]
Local b:Int[] = [1,2,3]
Local c:Int[] = a
If a = b Then Print "a = b"
If a = c Then Print "a = c"[/monkeycode]
This should only print "a = c". At the moment IIRC we can't do any kind of array comparison without trans complaining.


marksibly(Posted 2012) [#6]
Hi,

> I was hoping to be able to use a single nullable variant type basically, because at the moment I'm using Object and assigning boxed primitives.

Yes, I get that, but WHY?

Showing me some meaningless pseudo-code and saying 'I want to be able to do this' doesn't really clue me in on why some feature addition may be a good idea.

I can guess what you're trying to do - eg: given your lua project, perhaps you're trying to build some kind of dynamic variable environment where variables can 'not exist'...? But it'd be much better if you could explain what you're trying to achieve - in practical terms - yourself. That way, the feature request may make more sense and I may be more interested in adding it, or there may be another way of approaching the problem.

> This should only print "a = c". At the moment IIRC we can't do any kind of array comparison without trans complaining.

This was done largely to save confusion on the users end.

In particular, many people may well expect the above code to print "a = b" AND "a = c" - and why not? This is probably the more intuitive reading of '=', and it'd even work 'some of the time' if reference comparisons were added.

But at least element-by-element comparison can be manually - reference comparison cannot, so I'm not totally opposed to the idea...but again, why?

I've never needed to do this in any of my code to date, and given that it'd add a potential 'soft spot' to the language I'd really want more to go on before adding it.

I'd actually be really happy with a language that used full 'copy on write' semantics for arrays, as I'd be able to pass them around and save them in vars without having to worry about whether I should copy them first. This would make arrays true value types, and I'm a big fan of value types because no one can modify them behind yer back.

This is not really feasible in Monkey so it wont happen, but still, the reference comparison addition would really be taking things in opposite direction...why?


Gerry Quinn(Posted 2012) [#7]
I could have used a null array the other day for a class that could optionally maintain an array of pre-grabbed images from its own image file. If the array wasn't there it would grab an image if one was requested.

But it was easy to work around by initialising the array to have zero length by default.

Seems to me that whatever about strings, where an empty string can naturally appear as part of ordinary data, and so is hard to use as a null marker, zero-length arrays can handle most situations where you might like nullable ones.

I think I also like strings to be values always. But I am not a very sophisticated programmer ;-)

By the way, I take it that zero-length arrays are permitted everywhere? They seem to work okay, but I noticed that when I experimented with giving an array a negative length, the Monkey Runtime Error said the length must be a finite positive integer. I think that should be "a finite non-negative integer".


Samah(Posted 2012) [#8]
Referencing the same zero length array is somewhat of a performance optimization, but in my situation it's because I'd like a string to be optional but have an empty string as a valid value.

Mark, the reason I haven't given much of an example is because I'm not even sure how far I will take this Lua project and I didn't want to make any false promises. I'm trying to write a pure monkey implementation of the Lua VM so that it will work on all platforms without any externs. It's a huge task and I have no idea what kind of performance it will get (terrible, probably).