8.3 KiB
05 · 对象与成员
0/18 项已确认。当前推进 05-01；本分类尚未完成选择。
本页整理原讨论的问题、验收要求和候选方案。勾选代表讨论中已确认的规则，不代表编译器或运行时已经实现。
05-01 对象的基本模型
- 待讨论
完成标准：确定对象以记录、类实例、原型委托或明确的组合模型为基础；说明对象怎样获得数据和行为，是否必须存在类。
05-02 成员种类与命名空间
- 待讨论
完成标准：确定支持哪些成员种类；明确字段、方法、计算属性等能否同名，同名时如何处理。
05-03 成员集合与结构变化
- 待讨论
完成标准：确定成员是否预先声明，能否在运行时增加、删除或替换；说明非法变更的行为。
05-04 字段状态与可写性
- 待讨论
完成标准：确定字段是否有默认值、能否未初始化、如何表达只读；说明读取未初始化字段、非法赋值的行为。值与引用的具体规则依赖【类型系统／语言语义】。
05-05 方法接收者与方法取出
- 待讨论
完成标准：确定接收者如何传入；说明 f = p.move 后调用 f() 的含义，以及接收者不匹配时的行为。
05-06 计算属性与访问器
- 待讨论
完成标准：决定是否支持 getter、setter；若支持，明确读写触发规则、只读属性赋值及访问器递归的处理。
05-07 成员查找与缺失成员
- 待讨论
完成标准：确定查找顺序、遮蔽规则，以及成员不存在时是报错、返回特殊结果还是允许自定义处理。错误的发现时机依赖【类型系统】。
05-08 成员可见性与封装
- 待讨论
完成标准：确定公开、私有等访问范围及默认值；说明跨对象、模块、继承关系中的访问边界和失败行为。
05-09 对象创建与初始化
- 待讨论
完成标准：确定创建入口、初始化顺序、必填字段要求；说明初始化失败及初始化期间访问对象的规则。资源释放交由相关【运行时实现／语言语义】议题处理。
05-10 继承与委托关系
- 待讨论
完成标准：决定支持哪些关系、是否允许多个来源及关系变更；说明循环和非法关系的处理。是否形成子类型关系依赖【类型系统】。
05-11 组合与成员转发
- 待讨论
完成标准：确定组合对象的成员必须显式访问，还是支持自动转发；若支持转发，明确冲突、接收者和可见性规则。
05-12 覆盖与冲突约束
- 待讨论
完成标准：确定是否允许覆盖、是否要求显式标记、能否禁止覆盖；明确多个来源提供同名成员时的处理。签名兼容依赖【类型系统】。
05-13 方法分派
- 待讨论
完成标准：确定调用实现由什么决定，例如接收者或多个参数；说明重载候选冲突、无匹配实现的行为。依赖【类型系统】的部分单独标记。
05-14 调用上层或指定来源的实现
- 待讨论
完成标准：决定是否提供 super 或类似能力；若支持，明确查找起点及实际接收者。若不支持相关对象关系，明确其后果后可关闭此项。
05-15 类型级成员与共享状态
- 待讨论
完成标准：决定是否存在类／类型级方法和字段；明确访问方式、共享范围，以及它们与实例成员的关系。
05-16 外部扩展与行为替换
- 待讨论
完成标准：决定能否在定义之外添加方法、扩展成员或替换既有行为；明确作用范围、冲突和已有对象受到的影响。
05-17 公共基础接口、反射与内部字段边界
- 待讨论
完成标准：决定是否需要共同顶级类或公共基础协议；明确哪些成员信息可以检查，哪些运行时元数据不可作为普通成员访问。依赖【定制协议／运行时实现／内置与标准库】。
05-18 跨分类一致性验收
- 待讨论
完成标准：用一组贯穿示例检查创建、读写、方法调用、封装和行为复用；核对相关分类的已定规则，解决冲突及阻塞依赖。
当前问题的方案与语言对照
以下沿用原讨论材料；建议和参考语言的做法均不自动成为本语言规则。
05-01 当前要决定的是：对象的数据与行为，主要通过什么机制组织？ 这里先不决定继承、动态增删成员或类型检查。
下面是官方文档中的语言机制；“好处与代价”是供我们判断的取舍分析。
| 语言 | 规则与具体行为 | 好处、代价及对我们的启发 |
|---|---|---|
| Python | 用户通常通过类定义实例行为。例如类定义 move(self, dx, dy)，调用 p.move(3, 4) 时自动传入 p。类本身也是对象。官方文档 |
数据与行为容易集中组织；同时需要解释实例、类、方法绑定等关系。启发：选择类模型，仍需逐项决定这些规则，不能把 Python 的整套机制一并带入。 |
| JS | 可以直接创建对象，也可以通过原型共享行为。例如 p = Object.create(proto) 后，p.move() 可以找到 proto 上的方法。class 也建立在原型机制之上，普通实例方法通常位于原型上。ECMAScript 规范 |
对象创建和行为共享灵活；查找涉及自身成员与原型链，需要处理遮蔽和共享成员变化。启发：类语法与底层对象模型是两个决定。 |
| TS | 在 JS 之上提供静态类型检查。例如 const p: {x: number; y: number} = {x: 1, y: 2} 不需要定义类。普通对象类型主要按结构检查；运行时对象仍遵循 JS 语义。官方文档 |
可以描述“需要哪些成员”，而不要求对象来自同一个类；但这种类型描述本身不提供运行时成员验证。启发：对象如何构成，与类型如何判断兼容，应分开决定。 |
| Go | 结构体定义字段，方法单独声明并关联到接收者类型。例如为 Point 声明接收者为 *Point 的 Move 方法，然后调用 p.Move(3, 4)。方法不是任意对象上随手添加的函数属性，接收者基础类型必须定义在同一包内。语言规范 |
无须类也能组织数据与方法；扩展方法受到明确边界约束。启发：我们此前的 A 方案还应包含“记录／结构体＋关联方法”这一变体，不能只考虑独立函数。 |
| Rust | struct Point 定义数据，impl Point 定义关联方法；例如 move_by(&mut self, …) 可修改接收者。没有传统的结构体继承，行为抽象还可通过 trait 表达。方法文档、继承与多态说明 |
数据、关联方法和行为抽象可以分别组织；需要明确它们之间的规则。启发：方法、封装和多态都不必以类继承为前提。所有权与借用属于其他分类，不随此方案自动引入。 |
因此，仍保留三个主要方向，并把 A 说明得更完整：
- A．记录／结构体为基础：数据由记录或结构体表达；行为可以是独立函数，也可以有明确关联的方法。选 A 后，再明确这两种组织方式的关系。
- B．类与实例为基础：类集中描述实例的数据与行为。是否继承、能否动态扩展，继续按后续任务决定。
- C．对象与原型委托为基础：对象可以直接构造，通过其他对象共享行为；必须明确委托查找规则。
如果优先考虑基础机制较少、数据与行为关系显式，我建议从 A 中的“结构体＋关联方法”开始。 它能提供 p.move(...) 的使用方式，又不必同时引入类继承或原型链；代价是动态对象扩展需要另外设计。这只是建议，尚未定案。
你更倾向 A、B，还是 C？如果选 A，我们接着比较“独立函数为主”与“关联方法为主”。
讨论来源
《语言设计 05：对象与成员》，整理日期 2026-10-28。章节编号沿用原清单。