Re: encapsulating code properties

[Joel E. Denny]

On Mon, 13 Nov 2006, Paul Eggert wrote:

> "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).

I'll look up my exact specs and respond to this later.

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

I also discarded the first run, but I didn't think to mention it.

> >>         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.

My experience for that last point has not been the same.

> Things might be
> different if we were exporting this interface to the world, I suppose.

If it's good for the world, then I'm not quite sure why it shouldn't good 
for Bison developers... especially given that Bison developers readily 
come and go from the world.  In other words, the barrier to entry for 
Bison internals is rather high (in my recent experience), and clean 
internal API's should improve that situation I think.

Don't misunderstand me.  I do not plan to go on a crusade to restyle Bison 
internals all at once (or ever most likely).  I usually only try to 
restyle code that I have some other reason to touch... and sometimes not 
even then.

> 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++.

Do you have anything specific in mind?

> 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.

Ok, thanks, I'll try.