Empty state of a DateTime variable

einhugur

DateTime variable cannot be nothing. And I cold not find in the Documentation DateTime.Empty like .NET has.

So how do I represent empty state of DateTime variable ?

Doing the following to test what DateTime variable is by default returns 1 for the year......

var dt as DateTime

MessageBox(dt.Year.ToString())

Thanks

Björn

Garry

This was working as designed, but the design was not friendly enough.

DateTime is a value type in ObjoBasic, so it cannot be Nothing. An uninitialised DateTime defaults to the minimum representable date, which is 0001-01-01 00:00:00, so seeing dt.Year = 1 was expected.

I've added two helpers for the next release:

Var dt As DateTime

If dt.IsEmpty Then
  MessageBox("No date selected")
End If

There is also:

Var dt As DateTime = DateTime.Empty

DateTime.Empty is an alias for DateTime.MinValue, but it is the preferred spelling when you mean “no date has been set”.

So the short answer is: after the next release, use DateTime.Empty and dt.IsEmpty.

I deliberately chose not to add optional/nullable value types for this. While they are powerful, they also add a lot of conceptual weight: developers have to learn a second “maybe value” form, unwrap/check rules, how it interacts with method calls, assignment, overloads, generics, arrays, dictionaries, and runtime errors. For a BASIC-like language aimed at being approachable, that is a large increase in complexity to solve a fairly narrow usability problem.

For now, DateTime.Empty keeps the model simple: DateTime always has a value, method calls like dt.Year are always safe, and there is a readable built-in way to represent “not set”. It also matches existing ObjoBasic behaviour for other value types such as String, where the empty value is still a real value rather than Nothing.

https://feedback.objo.dev/feature/412

einhugur

Garry

DateTime.Empty is good indeed, Its same as .NET has it.

Garry

The only catch is that 1st Jan 0001 at midnight is considered "empty".

einhugur

Thats ok, I think its same for NET, that is that there is some base that is the empty. As in they dont have exclusive field in it to store empty.

bgrommes

I am not 100% sure how I feel about this because I've grown accustomed to nullable types and don't really have a feel for how much my need for them is just because it's a metaphor that's imposed on me by .NET (or by routine contact with relational databases where one has to deal with NULL in any case) or if there's some organic purpose for them that I will miss.

But I will say that i'm a big fan of minimizing cognitive burden wherever possible and I agree it's in the spirit of being an "approachable" language. And you seem to be exposing enough primitives to allow workarounds when one needs to deploy judicious amounts of additional abstractions.

Also, this is certainly one way to eliminate a whole class of null propagation issues!

Garry

It’s still sitting a little uneasy with me as I think a date could in theory be Nothing (for instance an optional field in a database). The challenge is having a way to indicate something is empty or non-existent without the overhead of worrying about nil object crashes or the syntax pollution of nullable types.

bgrommes

Garry There's probably not a clean / perfect solution. Here are a few thoughts that I hope might help you decide what to do.

As you know, in .NET System.Data, there's a (singleton?) DBNull.Value that's what comes back from data queries when a column value is NULL. In DataReaders (equivalent of RecordSet) you have to check for e.g. DataReader[columnName].IsDbNull or else check for DBNull.Value. Unfortunately there has to be something like IsDBNull in RecordSet because there's a distinct difference between, say, an integer value of zero and NULL because NULL is saying "uninitialized" or "unknown" or "not set" which is not the same as a potentially deliberately set value of zero; you can't know if it's a default or not. You HAVE to be able to distinguish between the two in many situations.

In my personal opinion I don't see a need for a DBNull.Value equivalent so long as a RecordSet can tell me, along with the column type info it already provides, whether the column is nullable in the DB schema in the first place (IsNullable) and whether the value in a particular row is NULL (IsDBNull). The first would tell me if I need to check for NULL and the second would tell me if a cell is NULL or not. IsNullable could either be a separate property of the column or it could be wrapped in what comes back from ColumNativeType(n) either by appending " NULL" to the type name or returning a TypeInfo-like class rather than a String.

IMO this decouples whether an incoming DB value is NULL from whether the receiving type is nullable in the first place. I don't think the Objo type HAS to be nullable or lose its value semantics just because it might receive NULLs from a database. That is, after all, only one use case for e.g. DateTime. But one just has to detect it when reading the query result, and retain it in some way if it's important to the app. You cannot ask apps to "fly blind" in this regard.

For DateTime specifically I think most devs will find DateTime.Empty / MinValue an acceptable way to retain this info. An actual need to store January first AD 1 is vanishingly rare.

But it's more of a problem with other value types. I suppose e.g. Integer.MinValue could be sacrificed in most cases to stand-in for NULL / Nothing but it will maybe seem awkward to those accustomed to null support.

The biggest problem is Boolean. There, you'd have to have a parallel Boolean to indicate nullility.

I guess this just moves the problem around, it doesn't make it go away. So it boils down to how much of a burden this becomes on the Objo developer. IMO tracking nullility in your own way isn't substantially worse than using nullables or other forms of null support, but what null support brings to the table is a standardized and disciplined way to go about it across any ObjoBasic codebase. It lubricates the exchange of ideas and makes random ObjoBasic code easier to understand and explain because there's a universal way of doing a basic thing.

OTOH C# (and VB.NET) got along without nullables for a long time. They were introduced sometime after .NET 2.0 IIRC. All we had up to then was DBNull.Value and the ability to see the underlying NULL in the incoming data. So I am not advocating a Manhattan Project to implement nullables and don't know that I ever will. I am just arguing for basic support in RecordSet for now. Sort of like IDataReader.IsDbNull without DBNull.Value. I think that will be adequate at least for a time.

bgrommes

By the way ... in .NET, someDataReader[columnNameOrNumber].ToString() returns the empty string for a field that is NULL in the database. I find this to be entirely satisfactory, although I don't like that at least in C#, I keep getting "this string might be null" warnings when it is manifestly never the behavior of ToString() to return a null string.

So it is correct IMO for a NULL [var]char / text DB field to return an empty string, but that does not mean that an empty string is a reliable proxy for a NULL field of that type. I did not cover, above, how one would track a null vs an empty string. I guess if I were populating a ListBox I would use the all-purpose Tag field for that (and possibly for other things) but would prefer that there were an IsDBNull Boolean property I could set. I am guessing this isn't really possible unless it were implemented by the underlying Avalon control. But a guy can dream ;-)