Hi Liya,
In general I think when a development guideline promotes readability
it is a good thing. Issues like these may be addressed on a case by
case basis, though.
best
Wes
On Sun, Dec 22, 2019 at 8:54 PM Fan Liya wrote:
>
> IMO, this question relates to something general and fundamental.
>
>
IMO, this question relates to something general and fundamental.
Generally, name alias leads to two results:
1) It makes writing code easier
2) It makes reading code more difficult
Personally, I prefer readability to writability.
However, I am wrondering if we have some general principles regardi
I created the following ticket (and sub-tasks) [1] to track
François
[1] https://jira.apache.org/jira/browse/ARROW-7438
On Tue, Nov 26, 2019 at 12:09 AM Micah Kornfield wrote:
>
> I would need to look at the other instances as well. I will try to so by
> next week, but I think we can probably
I would need to look at the other instances as well. I will try to so by
next week, but I think we can probably take an incremental approach of:
1. Eliminate *Ptr in src/arrow code (discuss similar changes in
parquet/gandiva).
2. Decide on the Iterator/Vector.
On Fri, Nov 22, 2019 at 10:47 AM W
hi Francois
On Fri, Nov 22, 2019 at 11:17 AM Francois Saint-Jacques
wrote:
>
> I'll revert, some questions:
>
> 1. Should we revert only the pointer aliases, or also the Vector/Iterator.
Could you clarify what Vector/Iterator aliases you are referring to,
like RecordBatchIterator?
I think we ma
I'll revert, some questions:
1. Should we revert only the pointer aliases, or also the Vector/Iterator.
2. Should we revert all modules, i.e. gandiva and compute.
François
On Thu, Nov 21, 2019 at 11:27 PM Micah Kornfield wrote:
>
> >
> > I think we should mostly be careful about public APIs. With public
> > APIs we should write out the types and avoid aliases. With
> > implementation details and private/protected class members, I think it
> > is fine to use aliases.
>
> I think we should mostly be careful about public APIs. With public
> APIs we should write out the types and avoid aliases. With
> implementation details and private/protected class members, I think it
> is fine to use aliases.
My concern with this is that in general if the types are in the hea
I think we should mostly be careful about public APIs. With public
APIs we should write out the types and avoid aliases. With
implementation details and private/protected class members, I think it
is fine to use aliases.
On Thu, Nov 21, 2019 at 11:06 AM Antoine Pitrou wrote:
>
> On Thu, 21 Nov 20
On Thu, 21 Nov 2019 08:40:10 -0500
Francois Saint-Jacques wrote:
> This notation is already used in some parts of the codebase [1]. I
> think it was introduced when absorbing gandiva and then in a draft of
> the logical operations in the compute module. I have no strong opinion
> for/against. I fi
This notation is already used in some parts of the codebase [1]. I
think it was introduced when absorbing gandiva and then in a draft of
the logical operations in the compute module. I have no strong opinion
for/against. I find it convenient to reduce typing, but the style
guide argue against this.
On Wed, 20 Nov 2019 20:50:12 -0800
Micah Kornfield wrote:
> A recent PR for datasets [1] seems to have introduced the convention of
> aliasing "std::shared_ptr" with "TypePtr" for some type. I think in
> the past we had decided not to use a convention like this but I can't find
> the thread. IM
A recent PR for datasets [1] seems to have introduced the convention of
aliasing "std::shared_ptr" with "TypePtr" for some type. I think in
the past we had decided not to use a convention like this but I can't find
the thread. IMO, I think this generally makes the code less understandable
but th
13 matches
Mail list logo
