From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58055 invoked by alias); 8 Aug 2015 06:44:51 -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 58043 invoked by uid 89); 8 Aug 2015 06:44:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-wi0-f173.google.com Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 08 Aug 2015 06:44:48 +0000 Received: by wibhh20 with SMTP id hh20so89871624wib.0 for ; Fri, 07 Aug 2015 23:44:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Pba97ERWH9t7lPotYNW7dkc0xYeGyaf4NZ8DTKTLvyw=; b=eFMQyxdTXlm4whWTYx8ZoJtXytkeFdL4WucSDhKLxfAEGsqsam2es6+c7ETKgmheGZ SFiLyGfadUfP5GBmtfshUqTiuH9ukBWDYFallGlHiD8ykBmtsrAxVtkH0FLwzDWhWk+h CU1Tg3+uUaZXlFJ7IUgR0anden+suxUQrKUZMWArZglgekqT8KAfSXsyp6YEX9u4PtUo NRTO7s45ZKWCi1GbfGBa7IcFgjj4FlxUvqMjWZAb7En+vK3UX9SP3gGJN4ah3F5Fqw3g FrtpwstLDGhhS4UY25jrUBQhCURrhCigKKsquWlAg22FXw0HaAiYGSSjLtU75wn/1oFu OOxA== X-Gm-Message-State: ALoCoQkTA3yifVKYKK+b/Iu5L7aAfl2PhsnPjnttVzO+lQ+dDn2npdA6i6rdnNXhXmZlVGVYF8DV X-Received: by 10.194.121.131 with SMTP id lk3mr22407926wjb.77.1439016283667; Fri, 07 Aug 2015 23:44:43 -0700 (PDT) Received: from localhost ([185.4.200.2]) by smtp.gmail.com with ESMTPSA id bq7sm18104297wjc.31.2015.08.07.23.44.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2015 23:44:43 -0700 (PDT) Date: Sat, 08 Aug 2015 06:44:00 -0000 From: Andrew Burgess To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v3 00/19] New completer API Message-ID: <20150808064442.GB2986@embecosm.com> References: <20150806191404.32159.50755.stgit@valrhona.uglyboxes.com> <20150807225655.GA2986@embecosm.com> <55C54778.2030004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C54778.2030004@redhat.com> X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00210.txt.bz2 * Keith Seitz [2015-08-07 17:04:08 -0700]: > On 08/07/2015 03:56 PM, Andrew Burgess wrote: > > I think that the above text is out of date w.r.t. the example below, > > in the above you talk about maybe_add_completion, but in the example > > below you use the add_completion wrapper. A small detail and > > unimportant detail; unless I'm missing something, in which case > > ... I'm confused! > > > > Yup, you're right. s/maybe_add_completion/add_completion/g. > > > I wonder, looking at add_completion, do users _care_ about the reason? > > Users? No. Developers? Yes. add_completion either returns ..._OK, Sorry, I should have said "users of the API". > 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. > My first reading of that would be "the addition was successfully > completed," but that's not what it means in this specific case, because > the return value indicates something entirely different. I agree with that point. > 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. 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. Thanks Andrew