From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78991 invoked by alias); 1 Dec 2016 19:04:22 -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 78976 invoked by uid 89); 1 Dec 2016 19:04:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=overlapping, HX-PHP-Originating-Script:rcube.php X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Dec 2016 19:04:20 +0000 Received: by simark.ca (Postfix, from userid 33) id BDCB91E144; Thu, 1 Dec 2016 14:04:18 -0500 (EST) To: Pedro Alves Subject: Re: [PATCH 19/22] Class-ify ui_out_impl X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 01 Dec 2016 19:04:00 -0000 From: Simon Marchi Cc: gdb-patches@sourceware.org In-Reply-To: References: <20161124152428.24725-1-simon.marchi@polymtl.ca> <1480173587-7053-19-git-send-email-simon.marchi@polymtl.ca> <8ca5a7eb3f6adac16c8db785bd9fa6d3@polymtl.ca> Message-ID: <22e3ae8a5895e196eeaa2393e2995bb6@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.2 X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00051.txt.bz2 On 2016-11-30 17:57, Pedro Alves wrote: > On 11/30/2016 10:38 PM, Simon Marchi wrote: > >> I'll consider working on merging ui_out and ui_out_impl_* in a single >> class hierarchy. My first question is: what is a good pattern for the >> overlapping methods. For example, table_begin. We'll want to execute >> the version of the base class, which will then call the >> specialization. >> So we can't use the same name for both. So, keep table_begin for the >> base class, and table_begin_impl for the derived classes? > > Yes. I think gold's convention is to use $method for public methods, > and > do_$method for protected virtual methods that implementations > override/provide. I've seen "do_" used for the same purpose in other > projects too. (IIRC, gold is even stricter and requires that virtual > methods must be protected, thus mandating that design everywhere. > Grep for "this->do_".) As I am doing this, I realize we'll need a cast anyway, it just changes where it is. For example, mi_cmd_var_list_children calls "mi_version (uiout)". The uiout variable is of type "ui_out *", since we don't know at compile time that the current_uiout will be an MI uiout. We know it will be because of how the program works, but that can only be verified at runtime. So in the end, instead of doing a dynamic_cast in mi_version, we'll have to do one in the function using the uiout. I still think that merging ui_out and ui_out_impl is a good idea though, there's no good reason for them to be separate.