arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Micah Kornfield <emkornfi...@gmail.com>
Subject Re: [DISCUSS] Result vs Status
Date Sat, 19 Oct 2019 01:18:28 GMT
Hi Wes,
Sorry for the confusion I agree completely with what you wrote.  I was only
thinking about scenario 2 and 3 (where it makes sense) in my previous email.

TL;DR; in the long term I don't think we should be supporting semantically
equivilent APIs for both Status and Result.

I'll see if I can get an estimate of APIs that would change

Thanks,
Micah

On Friday, October 18, 2019, Wes McKinney <wesmckinn@gmail.com> wrote:

> On Fri, Oct 18, 2019 at 7:58 PM Wes McKinney <wesmckinn@gmail.com> wrote:
> >
> > I'm definitely uncomfortable with the idea of deprecating Status.
> >
> > We have a few kinds of functions that can fail:
> >
> > 1. Functions with no "out" arguments
> > 2. Functions with one out argument
> > 3. Functions with multiple out arguments
> >
> > IMHO functions in category 2 are the best candidates for utilizing
> > Status. In some cases, Case 3 may be more usable Result-based, but it
> > can also create more work (or confusion) on the part of the developer,
> > either
>
> typo
>
> "category 2 are the best candidates for utilizing Result"
>
> > * The T in Result<T> has to be a struct-like value that transports
> > multiple pieces of data
> > * "Out" data may be split across a Result<T> and a separate out
> > argument. That's not too nice
> >
> > Can't say I'm thrilled about having Result<void> or similar for Case
> > 1-type functions (if I'm understanding what would be the solution
> > there).
> >
> > Left to my own devices I would either use only Status or use Result
> > when it is convenient for functions that have a single out argument
> >
> > I don't know how many functions or methods we have in the codebase
> > returning Status but I'd guess it's getting on the order of 1000. A
> > proper accounting would be helpful
> >
> > - Wes
> >
> > On Fri, Oct 18, 2019 at 2:41 AM Micah Kornfield <emkornfield@gmail.com>
> wrote:
> > >
> > > Based on the call this week, I think there are a few related questions
> here.
> > >
> > > 1.  Should we use Result at all?
> > >  - IMO Result expresses APIs more naturally then Status + Single output
> > > parameter.  I think most would agree if we had it from the beginning we
> > > would be probably use it.
> > > - The downside to using it is the pain in incorporating it into the
> > > codebase, including the potential for inconsistent APIs and breaking
> > > consumers of the package.  It also has the potential to cause ABI
> problems
> > > with other projects due its use of a vendored "Variant"
> implementations.
> > >
> > > 2.  If we agree on using Result in the code-base going forward (i.e. we
> > > don't remove it altogether), how do we move forward when working with
> APIs?
> > >
> > > This can be divided into existing and new APIs.
> > >
> > > For existing APIs we can:
> > > 1.  Leave existing APIs in place with no plans to migrate them to using
> > > Result.
> > > 2.  Aim to maintain both Result and Status APIs (backfill Result APIs
> where
> > > it makes sense).
> > > 3.  Aim to migrate to Result APIs (backfill Result APIs and deprecate
> > > Status APIs).  I assume this process will take at least 1 calendar year
> > > (its one of the things I'm hoping to get to).  This is probably best
> done
> > > incrementally by submodule.  I think for a change on this scale we
> should
> > > mark old APIs as deprecated and leave them in place for at least 2
> release
> > > cycles (at the current cadence 6 months).
> > >
> > > For new APIs:
> > > 1.  Attempt to always have both versions (Result and Status) of the API
> > > everywhere that it makes sense.
> > > 2.  Produce both versions of the API until we are ready to deprecate
> Status
> > > APIs in one go.
> > > 3.  Only produce APIs using Result.
> > >
> > > My personal preference would be to choose to use Result and proceed
> with
> > > Option 3 for existing APIs (aim for deprecation of Status) and Option
> 3 for
> > > new APIs (only use Result going forward).  My second preference would
> be to
> > > simply remove "Result".  I don't want to be supporting parallel APIs
> in the
> > > long term.
> > >
> > > Thanks,
> > > Micah
> > >
> > >
> > >
> > > On Sat, Oct 5, 2019 at 4:59 AM Sutou Kouhei <kou@clear-code.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > In <21183bb1-813f-b35b-b391-3f52ef2e62c9@python.org>
> > > >   "Re: [DISCUSS] Result vs Status" on Sat, 5 Oct 2019 12:23:05 +0200,
> > > >   Antoine Pitrou <antoine@python.org> wrote:
> > > >
> > > > >> OK, so what  could more context be provided on:
> > > > >>
> > > > >>> From the discussion in the sync call, it seems reasonable
to
> require
> > > > that:
> > > > >>> Public APIs which are likely to be directly wrapped in a
binding
> > > > should not
> > > > >>> use Result<> to the exclusion of Status. An equivalent
Status API
> > > > should
> > > > >>> always be provided for ease of binding.
> > > > >
> > > > > I don't know, sorry :-) I wasn't on the sync call.
> > > >
> > > >
> > > > We don't need Status API for bindings. We already use
> > > > complex types such as std::shared_ptr in our API. Bindings
> > > > need C++ feature for complex types. So we don't need to care
> > > > about Result<> or Status.
> > > >
> > > >
> > > > Thanks,
> > > > --
> > > > kou
> > > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message