From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40194 invoked by alias); 24 Jan 2018 18:01:09 -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 40162 invoked by uid 89); 24 Jan 2018 18:01:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*r:112 X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jan 2018 18:01:06 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w0OI10dE012230 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 24 Jan 2018 13:01:04 -0500 Received: by simark.ca (Postfix, from userid 112) id 0BEE21E5B7; Wed, 24 Jan 2018 13:01:00 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id E43681E074; Wed, 24 Jan 2018 13:00:58 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 24 Jan 2018 18:01:00 -0000 From: Simon Marchi To: Yao Qi Cc: Simon Marchi , GDB Patches Subject: Re: [PATCH 10/15] Class regcache_readonly In-Reply-To: References: <1512125286-29788-1-git-send-email-yao.qi@linaro.org> <1512125286-29788-11-git-send-email-yao.qi@linaro.org> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.2 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 24 Jan 2018 18:01:00 +0000 X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00485.txt.bz2 On 2018-01-24 12:37, Yao Qi wrote: > On Wed, Jan 24, 2018 at 4:57 PM, Simon Marchi > wrote: >> >> Just pitching some ideas, I don't think I understand the situation as >> well as >> you do. >> >> I assume we want to keep the "regcache" type to mean read/write and >> attached, >> since that's the most common use case. Keeping this will reduce the >> amount of >> changes needed throughout the code base. We can then qualify the >> other types > > Yes. > >> based on how they differ from "read/write" and "attached". That would >> give us >> (in the same order as your list above): >> >> - readonly_detached_regcache >> - detached_regcache >> - regcache >> - readonly_regcache > > This should be readonly_attached_regcache. The logic was that by "default" a regcache would be attached, unless specified otherwise (because that's what the plain regcache is). So that's why I suggested qualifying the detached regcache as such, while the attached ones would be implicit. >> >> This would give a predictable naming, and makes it maybe easier to >> know what >> to expect from each type. The graph you used in message 0/15 would >> become: >> >> reg_buffer >> ^ >> | >> ------+----- >> ^ >> | >> readable_regcache (abstract) >> ^ >> | >> ------+------ >> ^ ^ >> | | >> detached_regcache readonly_detached_regcache >> ^ >> | >> regcache >> > > This naming is fine to me except for readonly_detached_regcache > as it is too long. As "readonly" implies "detached" in current > context, > can we name it readonly_regcache? In this context readonly == detached, but aren't we going to want readonly attached regcaches at some point? If so, there will be a clash. Simon