[Swan-dev] [Swan-commit] modularity erosion
Antony Antony
antony at phenome.org
Thu Feb 14 06:56:03 UTC 2019
On Wed, Feb 13, 2019 at 11:33:01AM -0500, Andrew Cagney wrote:
> On Wed, 13 Feb 2019 at 04:41, Antony Antony <antony at phenome.org> wrote:
> > 2nd approach is move around definitions of struct. I imagine this is
> > Andrew's choice. Atleast in this case?
>
> This isn't true. The code evolution we're discussing here is truly
> unique. These are the declarations in question lifted, verbatim, from
> "proposals.h":
you are right. I was confused, probably a better naming and ideally less
code churn would help:) You are using a mix of #1 and #3 without
/* forward declaration */
You have good reasons and intention for these changes, however it is easy to
feel those as over complications.
My spontaneous reaction to this series of churn is not to use struct name as
variable names?
lets say I am following struct ike_proposals
then I would notice
proposals.h:177 struct ike_proposals {
ikev1.h:10 struct ike_proposals;
ikev2_parent.c:638 struct ikev2_proposals *ike_proposals =
look inside
proposals.h:177
struct ke_proposals {
struct proposals *p;
}
ikev2_spdb_struct.c:230
struct ikev2_proposals {
struct ikev2_proposal *proposal;
thanks for fixing the proposales code! I am happy with results in ikev2.
regards,
-antony
More information about the Swan-dev
mailing list