Re: encapsulating code properties

[Paul Eggert]

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

> My results disagree with yours.

Could be our development environments and/or CPUs, I suppose.  I'm
using a Debian stable environment (x86), but with GCC 4.1.1 installed.
My CPU is a 2.4 GHz Pentium 4 with 512 KiB cache, a 533 MHz FSB, and
512 MiB DRAM (ECC).

In all cases I did "make check" twice, once to bring as much as
possible into RAM, the second time for the actual timing.

>>         action_location_set
>>           (rules[ruleno].action,
>>            code_props_location_get (something_something_something_get (p));
>
> I see no problem with the latter case.

I do, unfortunately.  It's too wordy for what should be a simple
assignment "rules[ruleno.action].location = p->something.location".
There are some software-engineering advantages to the wordiness, but
some real disadvantages too.  In a small, self-contained project like
Bison the disadvantages tend to dominate more.  Things might be
different if we were exporting this interface to the world, I suppose.

Also, if we could use C++, we could eliminate a lot of the wordiness
as well.  But I wouldn't favor making that transition.  There are much
better choices than C++.

>> I have less strong feelings about this, partly because I don't use
>> Doxygen.
>
> I'm not sure what you're saying.  Are you willing to accept the "\c"?  
> Are you suggesting we drop Doxygen from Bison altogether?

The \c gets in the way of reading, but on further thought if you're
willing to maintain it I guess I'll live with it.  Please try to
minimize its use, though; if you can think of a different way of
wording that uses fewer instances of \c, that would be nice.