From dev-return-15519-archive-asf-public=cust-asf.ponee.io@arrow.apache.org Fri Oct 18 07:41:35 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id EF9311804BB for ; Fri, 18 Oct 2019 09:41:34 +0200 (CEST) Received: (qmail 30245 invoked by uid 500); 18 Oct 2019 07:41:33 -0000 Mailing-List: contact dev-help@arrow.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@arrow.apache.org Delivered-To: mailing list dev@arrow.apache.org Received: (qmail 30212 invoked by uid 99); 18 Oct 2019 07:41:33 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Oct 2019 07:41:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id EEDEBC109C for ; Fri, 18 Oct 2019 07:41:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id fKkhbAPKGTJ1 for ; Fri, 18 Oct 2019 07:41:31 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.167.53; helo=mail-lf1-f53.google.com; envelope-from=emkornfield@gmail.com; receiver= Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id C6797BCB94 for ; Fri, 18 Oct 2019 07:31:04 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id r2so3899201lfn.8 for ; Fri, 18 Oct 2019 00:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=cVT57nwY6N/8HfJzWbhVyzpAEH//sa+kY6MupdcSHOk=; b=nCAompqaKbHqwrT8HkyHQ49mk47yN3u56fus8peZOtbFrH/toDRuMfcwqjMKx8Z00Y JiBZnyi11yMY+MyG8YycKBvjrKpwYzfL2qf/LdNvxJ63xk7kw2j2ZnbCqtR6ujoY195k gymYccsaC74C4SILMQJ9sPm4/7AQABT7b2QomAzxd4ed0AoCaqDFZ3Y7JlFt6zYnSnK2 t5QTozJFEXHi40ey+q6NKZwyG92jFoeyd4gyFOEila/K9+lUZKTczrq4EEtxiHqDICnz VJodT6UqzE4ikVHSTdR27zUlMRb02oeklk8GOBU9Y5HfrtjCyo6qkzXV2J6xvWZurpeG AfEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=cVT57nwY6N/8HfJzWbhVyzpAEH//sa+kY6MupdcSHOk=; b=nIuLpgHIJtIUanQkE+51KOO45SAtqMex9bzXGWj1Ur9u50j4ZiC6zPJEc6Z9j4JEmu XSWTxM1SDBWeH0y9kss1sdzUC5a9gcDAvUig6CEULPPwSLzB4PNhruMlQBNkRQW9nfPH yzPj4kDqa1/SwF8UWt3uobQrqKZM/xRIii6Tah5JdUkcoSduv+MYafZikiYY9gWQcFxk BAmBOx3GGrSDthou+A55Wp5b+Li59h2VaLPlok1jPLf2Svbwc3HKgIBe8vN8jdklY0Xl SpYtQ2JedPbGyR4QG0GQmwvNKCp5jeVtUOWW1bwbwC+p9hj03xfUDbKjGDu71w/J7WwV D9Fw== X-Gm-Message-State: APjAAAXWXH7vxbt0AX5X7RNR0hBdHewnJZs2h1IL2yUfIr0d/4bPJB5g Hem83YCobFap853wdd2h+7wwECh30vl1Av5HRM4pF+c9 X-Google-Smtp-Source: APXvYqzJy65VIM84xw4LvCdQQCeKkKlDjWuuq9dY68lkvzPCk3H8xin61anODpkCPzfv8clCpsyYPFzQ9w6QP7E9c/o= X-Received: by 2002:a19:c192:: with SMTP id r140mr841594lff.48.1571383862913; Fri, 18 Oct 2019 00:31:02 -0700 (PDT) MIME-Version: 1.0 References: <5d8a8aa2-0c36-3e37-a4df-2663d4505389@python.org> <21183bb1-813f-b35b-b391-3f52ef2e62c9@python.org> <20191005.204934.1720707226652785828.kou@clear-code.com> In-Reply-To: <20191005.204934.1720707226652785828.kou@clear-code.com> Reply-To: emkornfield@gmail.com From: Micah Kornfield Date: Fri, 18 Oct 2019 00:30:51 -0700 Message-ID: Subject: Re: [DISCUSS] Result vs Status To: dev Content-Type: multipart/alternative; boundary="000000000000f46f6905952a5012" --000000000000f46f6905952a5012 Content-Type: text/plain; charset="UTF-8" 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 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 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 > --000000000000f46f6905952a5012--