[C++] Schema and StructType correspondence?

[Micah Kornfield <em...@gmail.com>]

It seems useful to be able to write code that could handle Schema and
StructType generically.

They both already define some methods (e.g. 'GetAllFieldIndices') that
would allow for this, but seems to be missing others.  For instance on
Schema access to  a field by index is done by 'field(index)' but on
StructType is done by 'children(index').

Is there a utility function that already works for generically handling
them?

If not is seems like there are two possible options:
1.  Create an adaptor facade that can be constructed with one of the two
types.
2.  Adding the missing methods 'field(index)' function to StructType or add
'child(index)' to Schema? If we pursue this approach do people have a
preference on trying to make a common ancestor interface and making these
virtual method calls?  Or using the naming correspondence inside of
templated code?

Thanks,
Micah

Re: [C++] Schema and StructType correspondence?

[Wes McKinney <we...@gmail.com>]

On Thu, May 7, 2020 at 3:34 PM Antoine Pitrou <an...@python.org> wrote:
>
>
> Le 07/05/2020 à 21:32, Micah Kornfield a écrit :
> > 2.  Adding the missing methods 'field(index)' function to StructType or add
> > 'child(index)' to Schema?
>
> Both sound fine to me.
>

There's a JIRA https://issues.apache.org/jira/browse/ARROW-3509 about
this. I might lean toward normalizing on the "field" name

> > If we pursue this approach do people have a
> > preference on trying to make a common ancestor interface and making these
> > virtual method calls?  Or using the naming correspondence inside of
> > templated code?
>
> Use the naming correspondence.  IMHO there's no reason for an interface.

Agreed

>
> Regards
>
> Antoine.

Re: [C++] Schema and StructType correspondence?

[Antoine Pitrou <an...@python.org>]

Le 07/05/2020 à 21:32, Micah Kornfield a écrit :
> 2.  Adding the missing methods 'field(index)' function to StructType or add
> 'child(index)' to Schema?

Both sound fine to me.

> If we pursue this approach do people have a
> preference on trying to make a common ancestor interface and making these
> virtual method calls?  Or using the naming correspondence inside of
> templated code?

Use the naming correspondence.  IMHO there's no reason for an interface.

Regards

Antoine.