From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120224 invoked by alias); 24 Jan 2018 17:37:18 -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 120215 invoked by uid 89); 24 Jan 2018 17:37:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qt0-f173.google.com Received: from mail-qt0-f173.google.com (HELO mail-qt0-f173.google.com) (209.85.216.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jan 2018 17:37:17 +0000 Received: by mail-qt0-f173.google.com with SMTP id d8so12413049qtm.0 for ; Wed, 24 Jan 2018 09:37:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t+CzbwWmzzEgZfpJidjRVHWBNmBRVrt6QMVFoZKCSy4=; b=gpKXJpN65tLkT4eth49mvXjhREjAHy8wpYJ3E0C2fU8OpQEeAhtJcQOlnAo0bn+eUd oD3n0rjjDF8bhlvYvC3XeSR/fnIRf0i9/Tn7FaIVylIpUJL9Sj742WCKl2MNusfFVJ9u YUn2PWUayJc+7CdluT/GcF0fdcPOv0gUyETlPXf9ENRr5d8cOV+ohQi24NAkI7flUmHW 6mgbL7c4U+iQJ+eDZXbcry5AwfL6KoVRQtx9N1KnXvC7/j0e3LwluDKuNsYmGcZycCda 65cVM2Kr1J0DVgSXuWFOHXJU8uyD5Cw17XhLpTMm0B/Md3jb0VvES5KR9aF9grsdy9fC ZiwA== X-Gm-Message-State: AKwxytemDbm7UGujGDCaNbMe6YJfkdB9EPRWvPU8UP/58E12/dU64tqZ v9/mOnbG2prCEU4idxo3Cj1IHBXwGW/zb4p10lQ= X-Google-Smtp-Source: AH8x226XtIU2QAOgMjx+gHzLJ6gXWTAAEJat/a4MFDgBvQCHZPx5+lo2OEpbLrwZnDUTlocY2qyikQjo9mJZ4NTbdZw= X-Received: by 10.55.247.5 with SMTP id q5mr10668510qkj.147.1516815435496; Wed, 24 Jan 2018 09:37:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.153.232 with HTTP; Wed, 24 Jan 2018 09:37:15 -0800 (PST) In-Reply-To: References: <1512125286-29788-1-git-send-email-yao.qi@linaro.org> <1512125286-29788-11-git-send-email-yao.qi@linaro.org> From: Yao Qi Date: Wed, 24 Jan 2018 17:37:00 -0000 Message-ID: Subject: Re: [PATCH 10/15] Class regcache_readonly To: Simon Marchi Cc: GDB Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00484.txt.bz2 On Wed, Jan 24, 2018 at 4:57 PM, Simon Marchi w= rote: > > Just pitching some ideas, I don't think I understand the situation as wel= l as > you do. > > I assume we want to keep the "regcache" type to mean read/write and attac= hed, > since that's the most common use case. Keeping this will reduce the amou= nt of > changes needed throughout the code base. We can then qualify the other t= ypes Yes. > based on how they differ from "read/write" and "attached". That would gi= ve us > (in the same order as your list above): > > - readonly_detached_regcache > - detached_regcache > - regcache > - readonly_regcache This should be readonly_attached_regcache. > > This would give a predictable naming, and makes it maybe easier to know w= hat > to expect from each type. The graph you used in message 0/15 would becom= e: > > 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? --=20 Yao (=E9=BD=90=E5=B0=A7)