This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 3/5] Introduce gdbpy_subclass and use it to simplify some logic
- From: Tom Tromey <tom at tromey dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Simon Marchi <simon dot marchi at polymtl dot ca>, Tom Tromey <tom at tromey dot com>, gdb-patches at sourceware dot org
- Date: Thu, 09 Feb 2017 11:51:56 -0700
- Subject: Re: [RFA 3/5] Introduce gdbpy_subclass and use it to simplify some logic
- Authentication-results: sourceware.org; auth=none
- References: <20170115134253.24018-1-tom@tromey.com> <20170115134253.24018-4-tom@tromey.com> <b09a73b52d2c9365580e4462b463719b@polymtl.ca> <14228db3-a759-a117-e088-2542da718106@redhat.com>
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>> I don't really like gdbpy_subclass, I think there should be "ref" in the
>> name to be clear. So it could be gdbpy_subclass_ref. However, I find
>> gdbpy_subclass_ref<gdbpy_breakpoint_object> a bit long. As you may have
>> seen in my version of the patch, I had decided to keep gdbpy_ref for
>> PyObjects and introduce typedef for other types (gdbpy_inf_ref). So I
>> could see one called gdbpy_bp_ref.
>>
>> Otherwise, I like gdbpy_ref<> and gdbpy_ref<gdbpy_breakpoint_object>.
Pedro> I agree. Simon's gdbpy_ref_base + typedef idea would work for me too.
This patch would mean introducing 12 typedefs, most used (so far) in a
single spot.
That doesn't seem so great to me, so I think I will look at the
gdbpy_ref<> rename instead.
Tom