Re: Why do functions objfpy_new and pspy_new exist?

[Phil Muldoon <pmuldoon at redhat dot com>]

On 24/09/14 22:38, Doug Evans wrote:
> Hi.
>
> Normally, python wrappers of gdb objects are created with a
> foo_to_foo_object function.
> E.g., objfile_to_objfile_object and pspace_to_pspace_object.
>
> So why do objfpy_new and pspy_new exist?
> [defined in py-objfile.c and py-progspace.c respectively]
>
> IOW, when would one ever usefully do something with
> foo_objfile = gdb.Objfile()
> or
> foo_pspace = gdb.Progspace()

I can't think of a reason.  But someone else might.  Anyway the point
is moot (unfortunately) as we have an API promise, so they get to
stay.  Forever.

> ?
>
> This question applies to pretty much every gdb object that can be
> wrapped by Python.  I can imagine maybe a few objects where it would
> be useful to create non-gdb-wrapped python objects of some type.
> But I'd expect such cases to be rare.
>
> Am I missing something?

I don't mind cleaning up the actual "new object" code, but the calls
must remain.  However we re-factor internally, the API must not loose
functionality.  (I am in effect, stating this "as obvious" for the
lists and archives in case it comes up again.  I am sure you already
knew about it ;)

>
> I ask because we've got some duplicated code, two copies of the
> gdb.Objfile and gdb.Progspace constructors
> (objfpy_new + objfile_to_objfile_object,
> and pspy_new + pspace_to_pspace_object),
> and I think some cleanup is in order.

Being a pedant here, but this really should have gone to
gdb@sourceware? I personally prefer design decisions to be discussed
on that list.  gdb-patches@ is far too high in traffic and stuff
might get missed.

Cheers,

Phil