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 Fri, 18 Oct 2019 07:30:51 GMT
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