jorgecarleitao commented on pull request #9624:
URL: https://github.com/apache/arrow/pull/9624#issuecomment-790976766
fwiw, I think that there is a different way of approaching this.
The only reason we are implementing to_isize/to_usize on NativeTpe is
because we have a function to represent an array (for `Display`) that accepts a
generic physical type T, and then tries to convert it to a `isize` depending on
a logical type (`DataType::Date`). However, there is already a Many to one
relationship between logical and physical types.
Thus, a solution for this is to have the display function branch off
depending on the (logical) datatype, implementing the custom string
representation depending on it, instead of having a loop of native type T and
then branching off according to the DataType inside the loop.
I.e. instead of
```rust
for i in ... {
match data_type {
DataType::Date32 => represent array[i] as date
DataType::Int32 => represent array[i] as int
}
}
```
imo we should have
```rust
match data_type {
DataType::Date32 => for i in ... {represent array[i] as date}
DataType::Int32 => for i in ... {represent array[i] as int}
}
```
i.e. treat the `Display` as any other "kernel", where behavior is logical,
not physical, type-dependent.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
