I am spending some time on working on tables API. ...

# mathematics

[altavir]

I am spending some time on working on tables API. The question is about missing values. Does it make sense to add them in API? I mean, that coulmn type is T:Any, what should be default cell value return type T or T??

[Arthur]

What about having a explicit NullableTable<T:Any?> and an Table<T:Any> : NullableTable<T> . For the non-nullable you need to provide a default value which will be used for all null cells.

[altavir]

It would tremendously complicate API, because we will need to dublicate anything for nullable and non-nullable types. For now I am going with nullable returns overridden by non-nullables for primitive columns, but I really would appriciate input about that.

[altavir]

And I cant't use T: Any? because I need explicit KClass .

[altavir]

So my actual question: is the missing data a frequent case?

[Peter Klimai]

Is Table similar to a DataFrame? Data scientists seem to care a lot about possible missing data, e.g. pandas has methods like dataframe.fillna, etc.

[altavir]

I do not want to focus on DataFrame since it could not be fully translated to a type-safe language and Kotlin has some tools that are not available in python. But so far it looks like it is easier to work with nullables and then add optimized variants for primitives.

[Peter Klimai]

I agree nullables are better, this way users don't get into default values hell

[altavir]

Actually, this is the problem with nullables. For example, consider we are working with primitives and know that values could not be null, but the API still gives us nullable result, so we need to provide a readonable default for nulls. I think I will be able to solve that by providing specialized extensions for specific non-nulable cases.