ARROW-1685: [GLib] Add GArrowTableBatchReader

[kou]

No description provided.

[wesm]

Some functions like this (which have no novel methods) could instead return instances of the base RecordBatchReader, in case that helps make things simpler

[kou]

Sorry. I couldn't understand what you want to say.
You say that "is it better that the function returns GArrowRecordBatchReader (base class object) instead of GArrowTableBatchReader (specific class object)?", right?

Short answer: I don't think so.

In GTK+ case, it's true. GTK+ uses GtkWidget as a base class. Many methods accept GtkWidget as argument. So, returning base class (GtkWidget) object instead of specific class (GtkComboBox) object by specific class constructor such as gtk_combo_box_new() makes code simpler. Users can avoid many casts.

In Arrow GLib case, there are no class that are accepted many methods. So, there are only small merits. And GObject Introspection based bindings don't care about return type. They use real class of the object on run time because GObject (object system based on GLib) provides API to get class from object on run time.

I think that returning GArrowRecordBatchReader (base class object) instead of GArrowTableBatchReader (specific class object) isn't reasonable in Arrow GLib case. There are small merits for C API users (not language bindings users). Return type information is reduced in documentation side (returning GArrowTableBatchReader is more meaningful than returning GArrowRecordBatchReader).

[wesm]

Got it, thank you. I was mostly asking for my own understanding of how the GObject Introspection bindings work

On the C++ side in most cases we would want to use std::shared_ptr<RecordBatchReader> for generic handling of streams, where all you care about is the ReadNext method. In the Python bindings there would be not much benefit to creating a new wrapper type for the subclass unless it has some unique methods that you wished to expose.

[kou]

Thanks for explaining background. I understand.

In the Python bindings there would be not much benefit to creating a new wrapper type for the subclass unless it has some unique methods that you wished to expose.

It's reasonable. Arrow GLib can also choose the design.

In my experience, creating a new wrapper type for the subclass helps us to debug something. "Easy to debug" is very important for me. :-)

[wesm]

+1