Re: [RFC v2 01/38] add "this" pointers to more target APIs

[Doug Evans <dje at google dot com>]

On Fri, Feb 7, 2014 at 9:19 PM, Doug Evans <dje@google.com> wrote:
> On Thu, Feb 6, 2014 at 12:54 PM, Tom Tromey <tromey@redhat.com> wrote:
>> A subsequent pass introduces delegation helper functions to the target
>> API.  This delegation is much cleaner if the target_ops pointer is
>> directly available at delegation time.
>>
>> This patch adds the "this" pointer to various to_* methods for this
>> purpose.
>>
>> This updates a number of ports which I am unable to test.  Please give
>> them a look-over.  Any possible problem here is trivial, though, as
>> all that is required is adding an argument to a function.
>
> Hi.
> I'm *not* suggesting wholesale changes (babysteps is totally fine with
> me), but there's something I'm not sure about.
>
> I think it was on IRC where there was a discussion of passing the
> (pseudo-)vtable pointer as the self/this parameter being less
> preferable to passing a more canonical self/this which in turn has the
> (pseudo-)vtable pointer.  In this case we might not need such a change
> until such time as we've already converted to C++ (and thus taking the
> next step now could be time best spent elsewhere).  My question is to
> ask for clarity on where you see the target API headed.  Will we need
> a more canonical self/this pointer soon(-ish)?

As an example (just in case there's some confusion),
one thing I'm thinking about is global state used by targets.
If, for example, we support multiple remote connections then we're
going to have multiple open sockets/descriptors and IWBN if the
target_ops methods fetched such things from "self" instead of global
variables (*1).

I could be missing something of course.

---
(*1): I can imagine a temp hack of keeping such global variables
around and saving/restoring them when we switch targets (so that we
didn't have to update each target_ops function), but that's a bit of
work in itself, and I think(!) it would be preferable to skip that
step.