My original thoughts is that introduce a new interface makes the hierarchy a
little confused (FixedListVector->BaseListVector,
ListVector->BaseRepeatedVector->BaseListVector) and should try to avoid
introducing new classes.
And you are right, FixedSizeListVector should not include offsetBuffer,
>
> You are right, the mainly difference between FixSizedListVector and
> ListVector is the offsetBuffer, but I think this could be avoided through
> allocateNewSafe() overwrite which calls allocateOffsetBuffer() in
> BaseRepeatedValueVector, in this way, offsetBuffer in FixSizedListVector
> will r
Thanks Jacques, to avoid complex call paths for getObject, should keep
getObject for both classes. I'll also checked for other methods.
Thanks,
Ji Liu
--
From:Jacques Nadeau
Send Time:2019年8月11日(星期日) 21:43
To:dev ; Ji Liu
Cc:emko
We tried to get away from this kind of back and forth with subclassing as
much as possible. (call getObject on base class which then calls getIndex
on child class which then calls something else on base class). I haven't
looked through the code but let's try to avoid having complex call paths
for t
Hi Micah, thanks for your suggestion.
You are right, the mainly difference between FixSizedListVector and ListVector
is the offsetBuffer, but I think this could be avoided through
allocateNewSafe() overwrite which calls allocateOffsetBuffer() in
BaseRepeatedValueVector, in this way, offsetBuffe
Hi Ji Liu,
I think have a common interface/base-class for the two makes sense (but
don't have historical context) from a reading data perspective.
I think the change would need to be something above
BaseRepeatedValueVector, since the FixedSizeListVector doesn't contain an
offset buffer, and that f
