Re: [PATCH 19/22] Class-ify ui_out_impl

[Simon Marchi <simon dot marchi at polymtl dot ca>]

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.