On Fri, Feb 19, 2021 at 10:30 AM Micah Kornfield wrote:
>
> >
> > Agreed on Array::data(), in fact I made this change in #9490 (ARROW-9196)
>
> Thank you!
>
>
> > One convention I'd like to append: we mostly avoid convenience typedefs,
> > but an
> > exception is the common case of `vector>`, for
>
> Agreed on Array::data(), in fact I made this change in #9490 (ARROW-9196)
Thank you!
> One convention I'd like to append: we mostly avoid convenience typedefs,
> but an
> exception is the common case of `vector>`, for
> which we
> allow and encourage the use of `{class name}Vector`
I don't think there's any benefit in keeping RecordBatch abstract.
Making it concrete would probably reduce overhead slightly as well.
People who need abstract tabular data capabilities can still implement
Table (though I wonder if that ability has ever been used productively).
Regards
Thanks for looking into this, Micah.
One convention I'd like to append: we mostly avoid convenience typedefs,
but an
exception is the common case of `vector>`, for
which we
allow and encourage the use of `{class name}Vector` typedefs. (Conversely,
nothing
should be named /^\w+Vector$/ which isn't
(Apologies if this is a double send)
I'll open a PR on this soon. To update the dev guide.
Given this standard there are few accessor methods that I think we should
either convert or create a new accessor that does the correct thing with
respect to return type. Given how core these methods are
Agreed. We should probably document this in the C++ developer docs.
On Mon, Feb 8, 2021 at 12:04 PM Antoine Pitrou wrote:
>
>
> Hi Micah,
>
> That's roughly my mental model as well.
>
> However, for 4) I would say that return a const ref to shared_ptr if
> preferable because the caller will
Hi Micah,
That's roughly my mental model as well.
However, for 4) I would say that return a const ref to shared_ptr if
preferable because the caller will often need the ownership (especially
with Array, ArrayData, DataType, etc.).
Regards
Antoine.
Le 08/02/2021 à 18:02, Micah Kornfield a
I'm not sure how consistent we are with how shared_ptr is used as a
parameter to methods and as a return type. In reviewing and writing code
I've been using these guidelines for myself and I was wondering if they
align with others:
1. If a copy of a shared_ptr is not intended to be made by the
