Re: encapsulating code properties

[Paul Eggert]

"Joel E. Denny" <address@hidden> writes:

> If your results differ from mine, please post the test grammar so 
> I can see what you're seeing.

My benchmark was "time make check".  I don't recall the timings right
now, but it was a performance hit in the 1-2% range.  If this were
just one patch and it had some major countervailing advantage that
would be fine, but I have the feeling that more patches like this
are coming down the pike so I thought I'd raise the issue now.

> In my experience, it's painful to find and rewrite all appearances
> of A->location to code_props_location_get (A) when you suddenly
> realize you want some extra code like that at every access.

I'm afraid I'll have to disagree, at least for this particular case.
The code will get even harder to read, the more we apply this kind of
transformation.  Instead of the proposed:

        rules[ruleno].action_location =
          code_props_location_get (p->action_props);

we'll evolve to:

        action_location_set
          (rules[ruleno].action,
           code_props_location_get (something_something_something_get (p));

whereas I'd much rather see:

        rules[ruleno].action.location = p->action.location;

> If we tried abbreviated names like cprops_loc_get, would that address your 
> concern at all?

A bit, but not much.

> For me, the ALL_CAPS style seen in pre-Doxygen areas of Bison is
> harder to read and offers no way to distinguish between some_name
> and SOME_NAME, which might be two different symbols.

I have less strong feelings about this, partly because I don't use
Doxygen.