(除了版式上的不同)这个图与此前的图并没有本质的区别，我们仍然可以按上述遍历规则得到一个执行顺序——如果你将这个图理解为基于运算的排序的话。但是，我们这里要讨论的是基于数据的排序，即：运算影响到哪些数据，以及其影响先后的问题。基于此前的讨论，我们可以将“数据”理解为运算所需的参考——上下文环境，0ASSIGN(:=)STATEMENT(;)IDENTIFIERASSIGN(:=)IDENTIFIERASSIGN(:=)IDENTIFIER(i)ASSIGN(:=)OP(*)OP(+)IDENTIFIERSTRINGIDENTIFIERIDENTIFIER图2-17基于数据的排序：将“数据”理解为运算所需的参考□将图2-6中树的每一个运算放到它所需的上下文环境中，并□将这些环境用框图及其层次表达出来②。

可见，本质上来说，我们要正确处理此前的代码文本，则意味着我们将对上下文环境的相关性进行排序：内层是被依赖的，因此排序优先级更高；同层不存在数据/上下文环境依赖，因此优先级相等(例如1与3、2与4)。

比较两种方案：以数据为顺序时，标识符的作用域(亦即是上下文环境)问题将会绑定在语法树上；而以逻辑为顺序时，作用域问题与语法树是无关的。

①其一，图中的1~4为代码行号。其二，为方便绘制，图中省去了直接值结点，只留下表示数据依赖关系的标识。②内层的环境是外层的环境的一个参考，或称之为历史环境的一个映像。

所有被计算的数据，我们要么看做是顺序存储的值，要么看成是散列存储的“名/值”。但这只是对数据全体的一个认识。针对其中一个局部，例如某几个地址上的连续数据，或某几个“名/值”数据，我们又如何认识它呢?它们在数据概念上又是什么?在顺序存储中，我们已经为这样的数据找到了一个“看起来合理”的名字：结构类型/结构体。基于这一存储方式的特点，我们对结构体中的“字段名”并不敏感，例如说：// C Syntaxstruct info {char first[10];int age;5 };这个结构有first和age两个字段名，但忽视这两个字段名，我们以下面的结构体来操作它：struct info {1char data[14];23 };也没有什么不同。更进一步，它与一个字节数组也没有什么不同：1 byte info[14];但是散列存储中的某几个“名/值”数据就不可能这样消化掉了。例如：// JavaScript Syntaxinfo ={name: 'Tom',age: '32!6 };其中name与age这两个名值对，其内部是有依存关系的——它们分别是info的不同性质；也有其外延，即可以作为其他的数据的性质，例如：①在一个语言的具体执行环境中，还涉及边界对齐问题。

如我们此前讨论的，name、age(以及更多个)这样的名/值构成了一个数据系列，并满足了我们对数据的内涵与外延的定义，因此它必然可以被理解为数据。而其作为数据，其何种系列的抽象，亦必将为一种数据结构。yipindushu.com

这种系列的抽象，我们称为对象。对象是一种数据结构，其每一个分量数据为一个属性，属性可以是对象、索引数组、关联数组，或它们基础的、延伸的数据类型之任一。

对象可以看成是关联数组的一个自然延伸。我们知道，关联数组在概念上与“去除存储限制的”索引数组可作类比；与此相似，对象与“去掉存储限制的”结构体也可作类比，图2-18表明了这样的关系。