alamb commented on pull request #984:
URL: https://github.com/apache/arrow-rs/pull/984#issuecomment-993476432
> but would adding a dyn Scalar trait mean having to update everywhere rust
native scalars are currently used with that trait?
One approach could be to remove all the rust native scalars and replace with
`dyn Scalar`, but another approach is to have both (keep the existing kernels
with different signatures, and add a new entirely dynamic kernel
`eq_scalar(&dyn Array, &dyn Scalar`).
I think keeping with the existing style of separate kernels for separate
rust native types for this PR is probable,
> of course this is assuming legal issues are resolved. on that point,
independent from the context of this PR, is IP clearance expected to refresh
anytime soon?
I defer to @jorgecarleitao on his plans, as he is the primary author of most
of arrow2
> The approach from @shepmaster seemed quite nice as well however would
still require users setting the type of the scalar - is that acceptable?
I think it is acceptable (and a good idea) personally. It would result in
perhaps something like:
```rust
/// Perform `left == right` operation on an array and a numeric scalar
/// value. Supports PrimtiveArrays, and DictionaryArrays that have primitive
numeric values
pub fn eq_dyn_scalar<T>(
left: &dyn Array,
right: T
) -> Result<BooleanArray>
where
T : IntoArrowNumericType
{
...
}
```
?
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
