ARROW-846: [GLib] Add GArrowTensor, GArrowInt8Tensor and GArrowUInt8Tensor

[kou]

No description provided.

[wesm]

As a way to reduce build times, have you considered consolidating code either by object type (all types / arrays / tensors in one place) or data type (e.g. all the uint8 things in one header)? One of the downsides of C++, I guess. It's not a problem either way

[kou]

OK. I'll choose object type based consolidation. Because it's suitable for organizing documentation.

Arrow GLib uses one class per file because documentation tool Arrow GLib uses (GTK-Doc) uses one document section per file rule.

Should I do the change in this pull request? Or can I work on the change as another pull request? I want to work on the change as another pull request to do one thing in one pull request.

[wesm]

@kou I see about GTK-Doc, I did not know that requirement. I will defer to your judgment; if you make any changes it's OK to do them in another pull request.

[wesm]

+1.

So one thing I'm wondering, and want your opinion. I am not sure if having all of the TYPENAME##Tensor classes is very useful, since they only provide a typed data pointer. We would make only a single Tensor class instead, would that make things easier for you?

[wesm]

cc @robertnishihara @pcmoritz -- I am considering removing the arrow::Tensor subclasses, but I want to see if you anticipate that causing any problems. I'm going to merge this PR for now

[wesm]

See https://issues.apache.org/jira/browse/ARROW-860

[kou]

It's OK to me that Tensor subclasses are removed.
If Tensor class provides a method that returns one element value like Array::GetValue(), Tensor subclasses are useful. But the current Tensor class doesn't provide it.

[pcmoritz]

@wesm I don't think we need the tensor subclasses, so ARROW-860 is perfectly fine. If people in the future want to write C++ application code to modify typed tensors we can reconsider.

[wesm]

OK. Sounds ogod