This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] [PATCH] Provide the ability to write the frame unwinder in Python
- From: Doug Evans <dje at google dot com>
- To: Andy Wingo <wingo at igalia dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>, guile-devel at gnu dot org
- Date: Wed, 18 Mar 2015 09:48:32 -0700
- Subject: Re: [RFC] [PATCH] Provide the ability to write the frame unwinder in Python
- Authentication-results: sourceware.org; auth=none
- References: <CAHQ51u7NUoQ8w9c5mc-Eiz05b1Nub6zqj_Ne7vfgWb5EP9_X8w at mail dot gmail dot com> <21714 dot 40641 dot 510825 dot 30998 at ruffy2 dot mtv dot corp dot google dot com> <CAHQ51u5_ViLaEmv9e43R-wzuWw8dwNkb-2XgCRy5ELQq5FUAWg at mail dot gmail dot com> <54E71694 dot 1080304 at redhat dot com> <CAHQ51u75+9HYAVJXYNQa0gTnQtYKEgmSkyAhAPYp-y4HGtXssg at mail dot gmail dot com> <CAHQ51u6UZ7A47rpGgX0QGeYSTCz1eo_3jWHc=q2ZX3YhqcJ6iQ at mail dot gmail dot com> <87ioei31uj dot fsf at igalia dot com> <CAHQ51u4f+Vx7qXPm-KAAENOceaVogMbDMw6==N_nY+GrLr4Pgg at mail dot gmail dot com> <87d24p19tt dot fsf at igalia dot com> <54FD7DAA dot 7010603 at redhat dot com> <CAHQ51u7sUkGhkmvTaaO_Jo6Jn+kojfiMWHmc2=7OWHThAq6EKw at mail dot gmail dot com> <87twxrncld dot fsf at igalia dot com> <CAHQ51u60nHp1a2DXZ4srvRefyTtge1BUw7-=JuYqChHN_wUGyQ at mail dot gmail dot com> <87ioe1dvu2 dot fsf at igalia dot com> <CAHQ51u7KzQLSLC=QeLA=zd+TUkbbNzzndfeVLFWpjiR-pL8ang at mail dot gmail dot com> <87sid4atms dot fsf at igalia dot com> <CADPb22RLqd=CB+KtiXA=Jdg-W3YzrsK4g0qBi_SNA8ATPhDyrQ at mail dot gmail dot com> <87mw3aadjv dot fsf at igalia dot com>
On Wed, Mar 18, 2015 at 1:57 AM, Andy Wingo <wingo@igalia.com> wrote:
> Hi,
>
> [-asmundak, as he probably doesn't care :)]
>
> On Tue 17 Mar 2015 23:21, Doug Evans <dje@google.com> writes:
>
>> On Tue, Mar 17, 2015 at 1:57 AM, Andy Wingo <wingo@igalia.com> wrote:
>>>> As to the class of an object passed to a sniffer, how about calling it
>>>> FrameData? Note that it's not very important from the user's point of
>>>> view as sniffer code does not ever reference it by name.
>>>
>>> It's true that from user code it barely matters to Python, but Scheme's
>>> monomorphic flavor makes these things more apparent:
>>>
>>> (frame-data-read-register frame "r0")
>>>
>>> This doesn't read so well to me -- is it "read-register" on a
>>> "frame-data", or is it "data-read-register" on a "frame" ? A weak point
>>> but "ephemeral-frame-read-register" avoids the question.
>>
>> As food for discussion,
>> I know some people use foo:bar in Scheme to separate
>> the object "foo" from the operation on it "bar".
>> -> frame-data:read-register
>
> This convention is not often used in Guile. When it is used, it often
> denotes field access rather than some more involved procedure call --
> similar to the lowercase "foo_bar()" versus camel-cased "FooBar()" in
> Google C++ guidelines.
>
>> I like having some separator, but I went with what
>> I thought was the preferred spelling (all -'s).
>> It's not too late to change gdb/guile to use foo:bar throughout (IMO),
>> but the door is closing.
>
> FWIW, I prefer "-".
Even though a different character solves a problem?
What problem does it introduce?
The comparison with _ vs CamelCase is apples and oranges.
They don't separate object/class name from method name.
If I were to invoke static method read_register on class
ephemeral_frame it would be ephemeral_frame::read_register().
The problem of the readability of frame-data-read-register
that ephemeral-frame-read-register attempts to solve
just doesn't arise. Same with frame-data:read-register.