Should null strings be equal to empty strings?

In general i am not yet sure, how to handle strings.

Null equals zero length : A list of methods that are relevant can be good.

Another question:
When shall DWT make a copy of the passed string?

Some methods that won't accept null strings:

TableItem.setText(char[]);
TableItem.setText(int, char[]);

While TableItem.setText(char[][]) actually will accept null strings, just ignoring them. This is not documented.

Since I don't know Java much, I'm not sure what purpose these lines really serve:

if (string is null) error (DWT.ERROR_NULL_ARGUMENT);

Why doesn't the Java version set it to an empty string if it's null?

I expect all the setText methods to behave like this, since the ones in Decorations and Item do. The various setMessage methods (like in MessageBox?) work the same way.

The getText methods, like Item.getText and Decorations.getText are documented like this: "If the text has not previously been set, returns an empty string". So returning null doesn't seem to be common. Again, someone with Java knowledge can probably tell me why. But it's at least a sign that null strings and empty strings are the same, since you won't be able to tell if the string has not been previously set, or was just set to an empty string.

An example of a method that distinguishes between null and empty strings is Control.setToolTipText(char[])

And Control.getToolTipText(char[]) returns null to signify that no tooltip text is set.

The tooltip set/get methods are special, in that they use null to signify if displaying tooltips is disabled or enabled. So allowing null is just a replacement for having setEnabledToolTip(bool enable) and getEnabledToolTip() methods, it's not about the actual text.

Conclusion: Like I said, I don't know why setText methods currently don't accept nulls. Maybe there's a good reason for it. With that caveat in mind, I would say that all setText and setMessage methods should accept null strings, and treat them the same as empty strings. That's the way strings are supposed to work in D.

---

I haven't really looked into when strings should be copied. But it seems to work the way it's currently done. In D 2.0 this will be easier, and maybe some copying can be avoided.

GC.drawString is another method that behaves like setText, not accepting null strings.

Is it possible that not accepting nulls is to catch bugs in user code? Things like this?

String s;
item.setText(s);  // oops, user probably meant to give s a value before using it

GC.drawImage does not accept null Images, which might be for the same reason.

On the other hand, TableItem?.setImage accepts null, which removes any image previously set. So it would seem that an 'empty' image is represented by null, while an 'empty' string is a non-null string of length 0. Or something...

In general both string arguments and array arguments are covered by this issue.

There is the general distinction between

1. Methods not accepting null
2. Methods accepting null and perhaps make a decision on null or not null.

For the first kind, i would say, every method that makes this check, can have it removed without danger.

I did this for dwt-linux in this revision 255.

Those changes are also documented here.

Perhaps someone like to do those changes also for dwt-win (including doc in wiki).

The second kind of methods needs be looked at carefully. A list of them is needed.

The second kind of methods needs be looked at carefully. A list of them is needed.

Do they need to be changed at all? I mean, they already accept nulls.

Yes, because they might not work properly.

API was changed to accept null args.

Is there any particular reason why TableItem?.setText still doesn't accept nulls? I've only looked at dwt-win, not linux.

No particular reason. I updated dwt-win/linux. The done changes are documented here: http://www.dsource.org/projects/dwt/wiki/DiffToOriginal

If i missed more, please report it.