规范化 `get_xxx_info`、`get_xxx_list` 动作的命名

[stdrc]

• 状态：关闭
• 相关 PR：无

摘要

把 get_xxx_info 动作改名为 get_xxx、get_xxx_list 改名为 get_xxxs。

动机

get_xxx_info 和 get_xxx_list 是 CoolQ 时代遗留下来的命名方法，已经和新的接口的命名方式不匹配（get_version、get_latest_events 等）。

不破不立，没有必要继续沿用旧的命名方式。新的命名方式会更符合英语表达习惯，且在视觉上更简练。

具体描述

• get_self_info -> get_self
• get_user_info -> get_user
• get_friend_list -> get_friends
• get_group_info -> get_group
• get_group_list -> get_groups
• get_group_member_info -> get_group_member
• get_group_member_list -> get_group_members

局限

旧的代码需要改名。

替代方案

无。

[crazywhalecc]

除去历史局限问题，新名称如果改为删除 list 的叫法，会模糊 API 本身的含义，比如 get_group 到底是获取群组的什么内容呢？

虽然确实考虑到简练，新标准内的部分动作已经实现缩短化处理，但 OneBot 标准内规定的动作我认为应该是需要更加具象化一点（具象化并非指还原 list 的叫法，是说比如是要更加约定俗成一点还是更加限制一点）。

目前标准感觉如果放开前缀的规定的话，那这边的分割词语用词也要讨论是否要规定了。比如 xxx_yyy_zzz 的结构中 xxx 代表动词，yyy 代表客体，zzz 可能代表客体小分类。或者就是随意发挥，完全放开 API 的规范化内容，从一开始就只把核心的 RPC 过程当作核心而不规定 API 具体传递的字符串内容和格式。

[stdrc]

比如 get_group 到底是获取群组的什么内容呢？

好问题，确实。其实我原意是想让 OneBot 的动作“以 <verb>_<class>_<property> 的形表现 RESTful 的实”，仔细想想可能还是保留 get_xxx_info 和 get_xxx_list 比较好（去掉有违和感的原因可能是因为我们没有明确定义 Group、GroupMember 等类型），我们就理解为，RESTful 里 GET /objects 的，我们用 get_object_list，GET /objects/123 的我们用 get_xxx_info。

目前的问题是元动作和其它动作的命名风格不一样，不过如果把元动作理解为特殊的存在也就可以了。

目前标准感觉如果放开前缀的规定的话，那这边的分割词语用词也要讨论是否要规定了。比如 xxx_yyy_zzz 的结构中 xxx 代表动词，yyy 代表客体，zzz 可能代表客体小分类。或者就是随意发挥，完全放开 API 的规范化内容，从一开始就只把核心的 RPC 过程当作核心而不规定 API 具体传递的字符串内容和格式。

我倾向于类似“xxx_yyyzzz 的结构中 xxx 代表动词，yyy 代表客体，zzz 可能代表客体小分类”的动作命名规范，也就是 `_`，可以作为一种“guide”，而不是强制性的（我们其实也没法强制）。

---

说到定义 Group、GroupMember 等类型，其实我考虑过在标准里定义这些类型，这样在动作、事件的描述里面可以直接说“某某动作返回 Group 对象”、“某某事件的某某字段是 GroupMember 对象”。

对标准接口进行扩展时，实际上可能在扩展这些类型，表现在代码上，可能是继承 LibOneBot 中定义的对应类型。

有什么想法吗？

[crazywhalecc]

对标准接口进行扩展时，实际上可能在扩展这些类型，表现在代码上，可能是继承 LibOneBot 中定义的对应类型。

如果是对 Action 的扩展，可以在代码层面对其余补充参数做一个可选声明，然后开发过程中自行判断是否存在，因为只规定了尽量使用标准的参数和动作。