[flashrom] [PATCH] Shorten some board enable related function names

[Carl-Daniel Hailfinger]

Am 21.08.2011 21:50 schrieb Stefan Tauner:
> On Tue, 16 Aug 2011 13:38:05 +0200
> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> Am 15.08.2011 23:42 schrieb Stefan Tauner:
>>     
>>> oh my. now that i see the code, i think renaming the board enables to
>>> board_match is really a bad idea. mainly because we use "match" as verb
>>> in other places, but here as substantive.
>>> e.g.
>>> static const struct board_match *board_match_cbname
>>> a function that matches boards according to their cbname should return
>>> a board, not a "board match". it is just a question of taste, but i
>>> find it awful :)
>>>       
>> It's a trap!
>> The struct is there to match a board, so struct board_match is exactly
>> the right name for the _type_.
>>     
> if that would be its only purpose, it would contain identification
> attributes only. last time i looked it had general info about boards
> (vendor and board name) and board enable specific fields (phase,
> max_rom etc). its previous name also suggests it is not just for
> matching. ;)
>   

Hm right.


>>> the wiki table is named board_info hmhm maybe board_detail, but that's
>>> long.. :/
>>> what about just "board"?
>>> another way to mitigate "my" problem would be to no use match as a verb
>>> for the method names, but using "get" or "find" instead.  
>>>       
>> "get" has the wrong semantic implication for the cbname matching, and
>> "find" as in board_find_cbname suffers from the same problem because
>> we're NOT interested in finding the cbname of the board, but rather in
>> looking for a board which matches the supplied cbname.
>>     
> i think the reason for our difference of opinion is how we view the
> table. for me it is a kind of database or container class. and we want
> to query it for objects with certain properties.
>
> in sane languages (supporting polymorphy) you could write that as
> <container variable>.find_board(cbname). of course "match" would work
> too, but as explained above i would like to use different terms just to
> have a (mental) distinction.
>   

Understood, your view makes sense. To be honest, my approach to renaming
functions is "would I misunderstand the purpose of the function?"


>> pci_dev_find() looks for a device matching the supplied vendor+dev IDs.
>> pci_card_find() looks for a device matching the supplied
>> vendor+dev+subvendor+subdev IDs.
>>
>> The name "card" was picked to allow differentiating between PCI devices
>> (cards) which share vendor+dev ID, but have different subvendor+subdev
>> IDs. That's pretty common for network cards where dozens of vendors use
>> the same network chip (and thus fixed vendor+dev ID), but completely
>> different PCBs.
>>     
> hm, ok
>
> well... it is certainly an improvement over the current state and this
> discussion wont lead to something more sane i feel, so think of it as
> Acked-by: Stefan Tauner <stefan.tauner at student.tuwien.ac.at>

Thanks, committed in r1424.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/