Re: [PATCH 2/8] fetch: move reference width calculation into `display_state`

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patrick Steinhardt <ps@xxxxxx> writes:

>> Given that in the previous step, what used to be called display got
>> renamed to display_buffer (I think "buffer" ought to be sufficient
>> in this context, though), the variable of "struct display_state"
>> type should NOT be named "display", as it would be confusing when
>> two things are related to "display" and only one of them is called
>> as such.  Either "display_state" or "state" would be fine.
>
> Fair enough. In that case I may just as well drop the first patch.

If you plan to get rid of an independent "display_buffer" in the
endgame by moving it into the bigger struct as its .buffer member,
then I think the naming is fine as there will remain only one thing
that is "display".  The fact that I didn't see that plan through
when I read only the first two patches would probably mean that the
route this iteration of the series took was somewhat roundabout, and
there may be a more transparent and possibly a more direct way to
get to that goal?

I am not entirely sure if the buffer should go inside the
display_state structure in the endgame.  An alternative may be to
make it a on-stack variable of format_display() (which will later be
modified to do everything up to and including writing out the
result) and pass it through the callchain below to its helpers, just
like the current code already does.  And in such an approach, you'd
still need to name that variable passed to the helper functions
called by format_display()---"buffer" would be a good name for that.

Just thinking aloud.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux