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: Andy Wingo <wingo at igalia dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>, guile-devel at gnu dot org
- Date: Thu, 19 Mar 2015 09:03:59 +0100
- 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> <CADPb22Q7dVwji-RKRhQJy4KNSnA_XgCn2W-J_r+1P25WMARcMw at mail dot gmail dot com>
Hi :)
On Wed 18 Mar 2015 17:48, Doug Evans <dje@google.com> writes:
> On Wed, Mar 18, 2015 at 1:57 AM, Andy Wingo <wingo@igalia.com> wrote:
>>
>> 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?
I find it to be uncommon style in Guile and so it doesn't appeal to me.
YMMV.
Of course, what appeals to me is a function of what is common, and I'm
sure anything can work well as long as it's consistent.
Adding a convention for using colons also makes me wonder when to use
colons or dashes. Perhaps that is my real objection.
Note that actually my original concern was not valid in this case;
"frame-data-read-register" is unlikely to be misread, because people
tend to break the name at the verb, if present. "read-register" on a
"frame-data".
> The comparison with _ vs CamelCase is apples and oranges.
At least in V8 there is a similarity; there are two conventions for
writing method names: underscores if it's a simple field access or
camel-case for more complicated things. Same decision criteria as colon
versus dash, as I understand the convention. You don't have the
subject/verb punctuation problem but you do have different ways to write
the verb based on what's going on underneath.
Doug if you want a specific coding style do let me know and I'm happy to
change. Please consider these comments to be just gut reactions /
reflections.
Andy