undefined | Better HN

0 pointslayer83y ago0 comments

A string being empty oftentimes isn’t semantically different from the value being absent. I’d argue that, this being the case, the type should also be able to reflect whether the string can be empty or not (or all-whitespace or not, etc.).

0 comments

turboponyy3y ago

I completely agree, but conventional database systems don't support dependent typing unfortunately. Given the constraints, the best you can do in this situation whilst remaining semantically consistent in the type signatures is to leave the field nullable and enforce value checks (e.g. can't be blank).

layer8OP3y ago

Database systems support constraint checks. Given that SQL isn’t statically typed, that’s almost the best you can do. The only lack is that you usually can’t bind constraints to a user-defined type name, so you have to repeat the constraint definition for each relevant column/table. But on the programming language side, dependent types (or something equivalent) would be appropriate, and I expect will become common practice at some point in the future.

turboponyy3y ago

I think we may have been talking past each other - I did mean SQL's CHECK() et al with "value checks". I agree with everything you've said.

1 more reply

JyB3y ago

This is almost always true but somehow often overlooked. There's almost always no reason to rely on "null" to mean "empty". A carefully chosen default value often does the job.

j / k navigate · click thread line to collapse

0 comments

turboponyy3y ago

layer8OP3y ago

turboponyy3y ago

I think we may have been talking past each other - I did mean SQL's CHECK() et al with "value checks". I agree with everything you've said.

1 more reply

JyB3y ago

This is almost always true but somehow often overlooked. There's almost always no reason to rely on "null" to mean "empty". A carefully chosen default value often does the job.

j / k navigate · click thread line to collapse