- 内容提要
- 序 1:程序里的世界
- 序 2:最后一层表象
- 关于本书
- 致谢
- 引言:简单的本源
- 篇一:计算系统
- 第 1 章 数,以及对数据的性质的思考
- 第 2 章 逻辑
- 第 3 章 抽象
- 篇二:语言及其面临的系统
- 第 4 章 语言
- 第 5 章 从功能到系统
- 篇三:程序设计的核心思想
- 第 6 章 数据结构:顺序存储
- 第 7 章 数据结构:散列存储
- 第 8 章 执行体与它在执行过程中的环境
- 第 9 章 语法树及其执行过程
- 第 10 章 对象系统:表达、使用与模式
- 篇四:应用开发基础
- 第 11 章 应用开发的背景与成因
- 第 12 章 应用开发技术
- 第 13 章 开发视角下的工程问题
- 第 14 章 应用程序设计语言的复杂性
- 篇五:系统的基础部件
- 第 15 章 分布
- 第 16 章 依赖
- 第 17 章 消息
- 第 18 章 系统
- 篇六:系统的基本组织方法与原理
- 第 19 章 行为的组织及其抽象
- 第 20 章 领域间的组织
- 附一:主要编程范式 及其语言特性关系
- 附二:继承与混合,略谈系统的构建方式
- 附三:像大师们一样思考——从 UML 何时死掉 谈起
- 附四:VCL 已死,RAD 已死
文章来源于网络收集而来,版权归原创者所有,如有侵权请及时联系!
7.2 欢迎来到 名/值 数据的世界
此前我们讨论到,所有的数据最终都可以被抽象为数组,或者说我们此前讨论的所有数据类型都可以视为数组类型的转义。我们也讨论到,如果一个数组能确定长度,则它总能在运行前被顺序存储;如果它不能确知长度,也可以通过指针来保证在运行中实现顺序存储。
但是我们似乎多了一个题设。我们需要设问:顺序存储是必须的吗?
顺序存储的必要性在于:
- 运算器需要通过一种简单的方法来找到数据;
- 可以通过地址的余量来确知存储的占用情况,进而给程序员控制它的可能。
但是这两项条件都是与机器实现有关的,前者是运算器寻址的需求,后者是存储器容量的限制。而这些——我们必须强调在思想上要突破所有的限制——不是“计算”所必须的。换言之,一个计算过程仅仅是 需要数据 ,并没有限制 用何种手段来获得数据 。
据此,只要其抽象结果不会影响计算过程,我们就可以将数据的那些 仅仅应用于具体语言实现的 抽象概念一一抽离。仍以下面的代码为例:
1 2 |
|
这一句代码(的语法),对应着四个语义:
- 有一个标识,记为
aNum
; - 其数据类型为
Number
; - 标识所指代的数据,其值是可变的(即,变量
var
); - 该数据当前值为 100。
当我们把“值可变”与“当前值”这两个——由存储问题推导出来的——概念抽离之后,一个数据就只有三个普遍含义了:
- 名字,即标识:
aNum
; - 值,即数据:
100
; - 类型,即数据类型:
Number
。
此前我们也提到过,顺序存储中我们可以将所有数据类型都视为数组的转义,因此我们也可以把“数据类型”从这样的系统抽象中抽离——当一个事物不存在类别含义时,也就无需识别它了。这样,这个数据抽象系统就只剩下了 1 :
aNum = 100
现在,我们来到了 “名/值”(name/value pair) 数据的世界。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论