Return-Path: 
 <dev-return-3927-apmail-curator-dev-archive=curator.apache.org@curator.apache.org>
X-Original-To: apmail-curator-dev-archive@minotaur.apache.org
Delivered-To: apmail-curator-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 8507B17A31
	for <apmail-curator-dev-archive@minotaur.apache.org>;
 Tue, 21 Apr 2015 22:24:59 +0000 (UTC)
Received: (qmail 95501 invoked by uid 500); 21 Apr 2015 22:24:59 -0000
Delivered-To: apmail-curator-dev-archive@curator.apache.org
Received: (qmail 95451 invoked by uid 500); 21 Apr 2015 22:24:59 -0000
Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@curator.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@curator.apache.org>
List-Post: <mailto:dev@curator.apache.org>
List-Id: <dev.curator.apache.org>
Reply-To: dev@curator.apache.org
Delivered-To: mailing list dev@curator.apache.org
Received: (qmail 95439 invoked by uid 99); 21 Apr 2015 22:24:59 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Apr 2015 22:24:59 +0000
Date: Tue, 21 Apr 2015 22:24:59 +0000 (UTC)
From: "Mike Drob (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12740939.1410489781000.67870.1429655099299@Atlassian.JIRA>
In-Reply-To: <JIRA.12740939.1410489781000@Atlassian.JIRA>
References: <JIRA.12740939.1410489781000@Atlassian.JIRA>
 <JIRA.12740939.1410489781419@arcas>
Subject: [jira] [Commented] (CURATOR-148) Order of modifiers on framework
 commands matters
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/CURATOR-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505922#comment-14505922 ] 

Mike Drob commented on CURATOR-148:
-----------------------------------

[~randgalt]

On the ML you said you'd like this to be part of a larger usability sweep. Can you elaborate?

> Order of modifiers on framework commands matters
> ------------------------------------------------
>
>                 Key: CURATOR-148
>                 URL: https://issues.apache.org/jira/browse/CURATOR-148
>             Project: Apache Curator
>          Issue Type: Improvement
>          Components: Client
>            Reporter: Mike Drob
>
> I only tested this with the {{CreateBuilder}}, but visual inspection makes me think that it is present on other operations as well.
> If I want to create a ZK node, using a bunch of the features that curator provides, I have to do it in a specific order. (Arguments removed for clarity)
> {code}
> client.create()
>     .compressed()
>     .withMode()
>     .withACL()
>     .inBackground()
>     .forPath();
> {code}
> If I unknowingly call {{inBackground()}} first, then the only methods available to me are the {{forPath()}} variants. Similarly, if I call {{create().withMode()}}, then there is longer a way for me to call {{compressed()}} on that object.
> Even more concerning is that it is impossible to call {{compressed()}} and {{withProtection()}} on the same chain, regardless of order.
> Since each of the fluent-style methods already returns {{this}}, it might make sense to modify each method as implemented on {{CreateBuilder}} to have a declared return type of {{CreateBuilder}}, taking advantage of covariant return types.
> Another option, with similar results, would be to remove many of the intermediate interfaces from {{CreateBuilder}} like {{ACLCreateModeBackgroundPathAndBytesable<String>}} and declare it to be: 
> {code}
> interface CreateBuilder extends Pathable<String>,
>     Backgroundable<CreateBuilder>,
>     Compressible<CreateBuilder>,
>     ACLable<CreateBuilder>,
>     CreateModable<CreateBuilder>,
>     ....
> {code}
> This option is very verbose, however.
> A disadvantage of both of these options is that it allows users to call methods multiple times. In some cases, like {{inBackground()}}, it won't matter. In other cases, like {{withACLs()}} we'd have to make a decision on taking an intersection or "last call wins" approach. That might even differ per call, so we'd have to have careful documentation on each.
> Another option is to simply document the behavior (probably on the {{create()}} method) and hope that users will see it. Maybe the best solution is to document in a minor release line, and then make breaking changes in a major version?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)