Re: [PATCH 15/16] gdb: make cmd_list_element var an optional union

[Simon Marchi <simon.marchi@polymtl.ca>]

> Yes, the usage seems to be quite close (from the command writer point of
> view).  The major diferences at the momment is:
> - Your setter returns a bool to let know the caller that the setting has
>   been updated where mine does not.  I should change that.

Returning a bool is necessary to be able to tell whether we should emit
an MI =param-changed notification or not.  I think that's the only use.

> Other than that, you should be able to fit your set_inferior_tty_command
> and get_inferior_tty (among others) in my framework quite easily, in a
> very similar way.
> 
> Your add_setshow_*_cmd are changed from something like
> 
>   commands.set->function.set_cmd.set_func.string = set_func;
>   commands.show->function.show_cmd.get_func.string = get_func;
> 
> to something like
> 
>   commands.set->var.set_accessor<var_filename> (set_func, get_func);
>   commands.show->var.set_accessor<var_filename> (set_func, get_func);

Great!

> (I should probably not set both accessors with one function, only one
> will ever be used).

Just for the sake of discussion:

Conceptually, I find it a little bit wrong that settings are "part" of
the set and show commands.  Ideally, I think a setting (or parameter,
the two terms are used almost interchangeably) should be decoupled from
the set/show commands.  There are various ways to read setting values,
show commands are just one of them.  So, every time some part of GDB
needs to look up a setting, it actually looks up the corresponding show
command.  I think that settings should be kept in their own registry,
indexed by name.  You would have one setting instance for "non-stop",
for example, with a getter and a setter function.  The "set non-stop"
and "show non-stop" cmd_list_element objects would both point to this
instance and use the setting's setter or getter function.

Other parts of GDB that need to access settings, like the gdb.parameter
Python function, would look up the settings registry.  For example,
gdb.parameter('non-stop') would look up 'non-stop' in that registry, and
not look up the 'show non-stop' command as it does today.

>> Also, could you provide a git branch with your latest patch?  It will be
>> easier than figuring out on what to apply it.
> 
> I have pushed my current work (still a work in progress) to the
> following branch on sourceware: users/lsix/refactor-typesafe-var.

Thanks!

Simon