From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127957 invoked by alias); 8 Aug 2015 16:25:21 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 127941 invoked by uid 89); 8 Aug 2015 16:25:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 08 Aug 2015 16:25:20 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 1444B8E22E; Sat, 8 Aug 2015 16:25:18 +0000 (UTC) Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t78GPHL4023390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Aug 2015 12:25:18 -0400 Subject: Re: [PATCH v3 00/19] New completer API To: Andrew Burgess References: <20150806191404.32159.50755.stgit@valrhona.uglyboxes.com> <20150807225655.GA2986@embecosm.com> <55C54778.2030004@redhat.com> <20150808064442.GB2986@embecosm.com> Cc: gdb-patches@sourceware.org From: Keith Seitz Message-ID: <55C62D6D.1000903@redhat.com> Date: Sat, 08 Aug 2015 16:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150808064442.GB2986@embecosm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00211.txt.bz2 On 08/07/2015 11:44 PM, Andrew Burgess wrote: >> I don't like boolean return values in this case. Forget knowing what >> happens under the covers (or now that you've read the proposed API). >> Just by reading "bool add_completion (struct completer_data *, const >> char *);" can you tell what the boolean return value means? > > No. But you could rename to > add_completion_then_should_more_completions_be_added (he jokes) > (though maybe add_completion_and_continue would work?). But > I would have just assumed a good comment was enough. I'll have to try and sneak something like that past Doug on some other series. :-) >> But now I wonder if I am missing something. Is defining an enum going to >> choke some compiler? Does it violate, or is it ambiguous in, the >> language? Or is it simply a matter of style? > > My response was certainly _not_ on any technical grounds, simply a > matter of style. As a general rule when I see every use of a > function be: > > function_call (args) == SAME_VALUE > > I tend to think, can't we just push the comparison (effectively) up > into the function_call. That's a valid point. Thank you for reminding me of that. With large patches like this (with multiple revisions), I can sometimes not see the proverbial forest, or I forget it's even there. > Anyway, it was just a passing thought based on a mild interest in this > code, having recently touched it, I don't think it's a big issue. I appreciate your comments. Keep 'em coming! Keith