From: Tom Tromey <tromey@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb@sourceware.org
Subject: Re: gdbtypes.h #defined field accessors
Date: Wed, 30 Jun 2010 21:51:00 -0000 [thread overview]
Message-ID: <m3hbkkrxzk.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20100628205701.GC2700@adacore.com> (Joel Brobecker's message of "Mon, 28 Jun 2010 13:57:01 -0700")
Joel> I don't know if this is relevant to this particular discussion, but
Joel> I tend to like opaque structures and accessors (setter/getter) functions,
Joel> and I try to use that when writing new code. The idea is that it's just
Joel> very easy to figure out who's reading the data, and who's modifying it.
Joel> Sometimes, it's the only way to go, because the data structures are
Joel> complex enough that we shouldn't expose their contents, but even for
Joel> simple data structures, this can be handy.
Yes, I agree. I was really referring to macro accessors.
Opaque data structures plus accessors can make for very nice APIs.
Still, some care must be taken -- struct value is a particularly bad
example, because although it is nominally opaque, in reality the API is
quite large and lets users do too much.
Jan> While it is not relevant to your "new code" note this is what I
Jan> miss on the GDB accessors - they would be (more) useful separated
Jan> into getters/setters. It would easily enable providing various
Jan> currently constant fields as dynamic DWARF blocks.
Agreed. This has been a problem for me when hacking GCC and Emacs as
well -- both of which use "both lvalue and rvalue" macro accessors.
This is one area where value, as gross as is it, is distinctly better.
Tom
next prev parent reply other threads:[~2010-06-30 21:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-24 19:57 Jan Kratochvil
2010-06-28 20:37 ` Tom Tromey
2010-06-28 20:57 ` Joel Brobecker
2010-06-30 21:51 ` Tom Tromey [this message]
2010-06-29 23:15 ` Jan Kratochvil
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=m3hbkkrxzk.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/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