From: ludo@gnu.org (Ludovic Courtès)
To: gdb-patches@sourceware.org
Cc: guile-user@gnu.org
Subject: Re: [PATCH, doc RFA] Add guile gdb parameter support
Date: Tue, 27 May 2014 07:01:00 -0000 [thread overview]
Message-ID: <87a9a3emdk.fsf@gnu.org> (raw)
In-Reply-To: <CAP9bCMRwKqi0q10TLDQg3bqQPQn1X251FM1SE=VcHHSw0So+xQ@mail.gmail.com>
Doug Evans <xdje42@gmail.com> skribis:
> + guile-user for more eyes
>
> On Mon, May 26, 2014 at 3:03 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Hi, Doug,
>>
>> Doug Evans <xdje42@gmail.com> skribis:
>>
>>> +@deffn {Scheme Procedure} parameter? object
>>> +Return @code{#t} if @var{object} is a @code{<gdb:parameter>} object.
>>> +Otherwise return @code{#f}.
>>> +@end deffn
>>
>> Thereâs the problem that in Guile âparametersâ are something different,
>> and âparameter?â is already provided by core Guile (info "(guile)
>> Parameters").
>>
>> Unless âparameterâ is the official (public) name for this in GDB, Iâd
>> recommend using a different name in the API, perhaps âknobâ or something
>> like that. WDYT?
>
> "parameters" is what the python side calls them, I think the name in
> gdb is pretty concrete.
> Not entirely so, but using a different name isn't without its own problems.
Yes, surely.
> fwiw, and I know a lot don't like this approach,
> but I personally intend to always import the gdb module with a gdb: prefix.
Yes.
[...]
> But I'd also like to hear your thoughts on the general solution of
> just saying the convention is to important the gdb module with a gdb:
> prefix.
I generally agree with the idea that name clashes are best handled via
module renamers.
I also think itâs convenient when obvious name clashes are avoided
altogether. For instance, at the GDB prompt, itâs easier if you just
have to type âguile (use-modules (gdb))â instead of the longer thing.
So Iâd really consider name issues on a case-by-case basis.
Back to this particular case, if the Python API already uses the term
âparameterâ, thatâs probably enough to argue that the Guile API should
use that name as well.
Thanks,
Ludoâ.
next prev parent reply other threads:[~2014-05-27 7:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-21 19:41 Doug Evans
2014-05-22 15:46 ` Eli Zaretskii
2014-05-26 22:03 ` Ludovic Courtès
2014-05-26 22:23 ` Doug Evans
2014-05-27 7:01 ` Ludovic Courtès [this message]
2014-05-27 8:51 ` Ludovic Courtès
2014-05-27 14:43 ` Doug Evans
2014-06-02 3:13 ` Doug Evans
2014-06-02 8:31 ` Ludovic Courtès
2014-06-02 15:21 ` Doug Evans
2014-06-02 20:50 ` Ludovic Courtès
2014-06-02 15:41 ` Eli Zaretskii
2014-06-03 9:02 ` Doug Evans
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=87a9a3emdk.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=guile-user@gnu.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