From: Stan Shebs <stanshebs@earthlink.net>
To: gdb-patches@sourceware.org
Subject: Re: FYI: minsyms documentation
Date: Thu, 22 Dec 2011 21:18:00 -0000 [thread overview]
Message-ID: <4EF39BD6.8080802@earthlink.net> (raw)
In-Reply-To: <m3y5u4tleo.fsf@fleche.redhat.com>
On 12/22/11 12:13 PM, Tom Tromey wrote:
>>>>>> "Stan" == Stan Shebs<stanshebs@earthlink.net> writes:
> Stan> On 12/21/11 6:34 PM, Tom Tromey wrote:
>>> I am checking this in on the trunk.
>>>
>>> Today I decided to try to document the minsyms API more or less the way
>>> I would like APIs to be documented in general. This patch implements
>>> that; it move documentation from function definitions to minsyms.h, adds
>>> an introductory comment about minsyms there as well, and it rearranges
>>> the header into a more logical order.
> Stan> I'm not liking this idea very much I'm afraid.
>
> Ok.
>
> Do you mean you want me to back out the patch?
> Let me know.
We don't need to be that hasty. :-) I'd like to see more thoughts and
reactions; if everybody else likes it, I won't stand in the way of progress!
>
> Stan> Second, this is potentially a very large change to the sources, but if
> Stan> it's incremental, then we get into a confusing situation where some
> Stan> files are changed, others are not, and some headers are half-changed
> Stan> because they service multiple source files.
>
> This is the present situation.
True, and certainly we should provide some sort of guidance on the point.
One way to look at it is if we assume that the transition to C++ occurs
at some point, what happens to current function head comments? Do they
tend to stay put, as explanation of a method's implementation, or do
they tend to migrate to class definitions in headers? Perhaps method
implementations won't often need head comment blocks at all, as the
interface is documented in headers, and anything interesting in the
implementation is described with inline comments as is is now.
Stan
next prev parent reply other threads:[~2011-12-22 21:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 4:44 Tom Tromey
2011-12-22 5:17 ` Joel Brobecker
2011-12-22 20:13 ` Stan Shebs
2011-12-22 20:21 ` Tom Tromey
2011-12-22 21:06 ` Eli Zaretskii
2011-12-23 4:21 ` Stan Shebs
2011-12-23 16:01 ` Eli Zaretskii
2012-01-02 22:08 ` Tom Tromey
2012-01-03 8:17 ` Eli Zaretskii
2011-12-24 7:45 ` Yao Qi
2011-12-24 13:21 ` Eli Zaretskii
2012-01-02 22:08 ` Tom Tromey
2012-01-03 8:18 ` Eli Zaretskii
2011-12-22 21:18 ` Stan Shebs [this message]
2011-12-23 10:38 ` Joel Brobecker
2012-01-02 22:14 ` Tom Tromey
2012-01-03 2:53 ` Joel Brobecker
2012-01-03 11:05 ` Pedro Alves
2012-01-03 13:21 ` commands.h and cli/cli-decode.h dups (was: Re: FYI: minsyms documentation) Pedro Alves
2012-01-03 14:57 ` commands.h and cli/cli-decode.h dups Tom Tromey
2012-01-03 17:11 ` Joel Brobecker
2012-01-05 11:40 ` Pedro Alves
2012-01-03 11:18 ` FYI: minsyms documentation Pedro Alves
2012-01-15 18:49 ` Michael Eager
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EF39BD6.8080802@earthlink.net \
--to=stanshebs@earthlink.net \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox