Null or Zero variable

[Rich Cassell]

This is an issue we have to be aware of as we are a payroll provider!

It's slightly easier for us in that there is never usually a situation to change a payment value of 0.00 to be null, the only example i can see of this is if the user wants to not only zero the payment for this period but also remove the payment item from the employee in question.

In all other occasions it is more common to have a value in a payment that you want to set to zero, or have a zero (null) you want to set a value to. This is obviously easy to spot using a "preScreen" / "postScreen" style comparison of the text box and data.

Generally, we opt to store values which could be either zero or null (and to mean different things), by storing as a String as BeeJay suggested. We have also in the past (Where it is appropriate) cheated and add a checkBox next to the text box which is selected when the item wants to be removed and not just set to zero... That's obviously not the most user-friendly way of handling it but in some cases it works more neatly than essentially guessing what the user meant.

Rich

[Jason]

Could you create your own type to represent a nullable integer? This class could have a protected Integer attribute which is set via a public method. The class could then have a method called something like "isNull".

For example:

class NullableInteger
protected Integer value
protected Boolean hasBeenSet

public void Set(value : Integer)
public Integer Value()
public Boolean IsNull()

The Set method would set the value and also set the Boolean "hasBeenSet" to true. You could also add a method to "unset" it as well if you needed to do that.

[allistar]

To simplify Jason's idea, you could have a new abstract class called NullablePrimitive which has subclasses for each primitive type yo uneed one for, each with an appropriately typed "value" property. Make this the child end of an inverse to the class that needs a nullable primitive (so there are deleted when the parent is deleted). I don't see much value for an "isNull" property when you can achieve that by simply deleting the NullablePrimitive object. If the object is not there, then the value is null, otherwise the value comes from the object. It's not an overly efficient mechanism as there is an additional object to dereference and bring into the caches, but under most conditions the performance implications wouldn't be too noticeable.

We do this with certain Strings to store what you would use an enum for in other languages. E.g. if a property has three possible values "Inclusive", "Exclusive" and "Other" we could store this as an Integer which refers to a constant. The problem here is that we now need a method or two to convert the Integer into a String for the user. We could simply store the string directly, but this is inefficient for space and makes it very hard to change the value of the String. Instead we have a "StringReference" which has an object to represent the String value, and the parent object points to the appropriate one. It more easily allows the end user to change the text without a massive data conversion script, and also allows us to much more easily localise the text.

[JohnP]

You could also use constants and methods on the Primitive types themselves, enabling you to use code like this:

i:=Integer.Null;
write i.isNull(); // writes "true"

The constants would define the magic numbers, and the isNull methods would check for those constants and return a Boolean. This seems simpler to me than adding new types, and more efficient. You could also add an "Uninitialised" constant with another magic number.

[allistar]

The constants would define the magic numbers...

The danger with this is that you'd have to be absolutely sure that the magic number isn't a valid value in the application. For a financial system I would imagine -Max_Integer would be fairly safe, though it's still an assumption that would need to be ensured. You could go with an Integer64 simply so the magic number is even less likely to be used in the real world.

[murray]

As we can see, the issue is one of design: the numeric value and the 'hasBeenUpdated' status are two different things.
A Jade Integer is a primitive data item that always has a valid numeric value, nothing else (just like a byte or a bit).
As such, it can be implemented very efficiently and adding extra attributes or features would reduce that efficiency.
As has been suggested here, these extra attributes can be implemented in a manner that suits the intended design.
Remember that many years ago mathematicians used to argue over whether zero should actually be a valid number.