This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [gold patch] Incremental 13/18: Dynamic relocations
- From: Cary Coutant <ccoutant at google dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Tue, 24 May 2011 11:35:58 -0700
- Subject: Re: [gold patch] Incremental 13/18: Dynamic relocations
- References: <BANLkTimP1wvUaTy8+F-32eFOS9_BKsWTJQ@mail.gmail.com> <mcrei3ojgy5.fsf@coign.corp.google.com>
> Sized_relobj_base is turning into a poor choice of names. ?It looks the
> heirarchy is now
>
> Object
> Relobj
> Sized_relobj_base
> Sized_relobj / Sized_incr_relobj
>
> I don't mind having Sized_relobj_base when just a couple of things refer
> to it, but it looks wrong when lots of functions use it. ?The name of a
> class should indicate what sort of thing it is, rather than its position
> in the class heirarchy. ?We should consider renaming, e.g.,
> Sized_relobj_base => Sized_relobj, Sized_relobj => Sized_relobj_file,
> Sized_incr_relobj => Sized_relobj_incr. ?I'm open to other suggestions.
Yeah, I started out with something like this, but (a) I couldn't come
up with a name I liked for Sized_relobj_file, and (b) I was trying to
avoid wholesale changes to so many other files that were otherwise
unaffected.
In the ChangeLog, should I enumerate all the files touched, or is it
better to just say "Rename x to y; change all references" in object.h?
-cary