Re: [PATCH 0/9] Starting to convert languages to separate classes

[Simon Marchi <simark@simark.ca>]

On 2020-05-11 6:35 p.m., Andrew Burgess wrote:
> This series starts the process of converting GDB's language structures
> into separate classes, one for each supported language.
> 
> In the first commit I actually perform the conversion, but do so in a
> way that basically doesn't change anything.  All the data is held in
> the base class, and accessed just as it was before.
> 
> In the following commits I begin converting function pointer fields
> within the language base class into real member functions.
> 
> I haven't converted all of the function pointers yet, I want to see
> what feedback this series gets before I invest any more time.
> 
> Further into the future I think it's possible that we could tweak the
> class hierarchy of languages, I do wonder if there will be some
> obvious inheritance around the c_language maybe, but I figure I'll
> convert all of the function pointers to methods first, then see what
> everyone implements.
> 
> My hope is that be performing this conversion it will be easier for
> people to add new methods into the language classes, to allow easier
> language specific specialisation, hopefully we should be able to
> remove some of the places where we check the language enum, and
> instead replace this with a method on the language class.
> 
> Further into the future, I wonder if some things like expression
> parsing, and maybe some of the value manipulation/printing code would
> be better off as methods within the language classes.
> 
> Anyway, I'd be interested to hear peoples thoughts on the series so,
> and of this as a piece of work in general, is this a good change or
> not.
> 
> Thanks,
> Andrew

Hi Andrew,

I looked through it, I think that's very nice.

Ultimately, I don't think we need to keep language_data, data fields can
be transformed into methods that return a simple value.  But I am fine with
what you have, it allows for the work to be incremental.

Simon