【问题标题】:Why are the 'context' and 'object' functions in Rebol different, but essentially the same?为什么 Rebol 中的“上下文”和“对象”函数不同,但本质上是相同的?
【发布时间】:2013-02-28 20:07:15
【问题描述】:

一方面我们有:

>> source object
object: make function! [[
    "Defines a unique object."
    blk [block!] "Object words and values."
][
    make object! append blk none
]]

我们看到的上下文:

>> source context
context: make function! [[
    "Defines a unique object."
    blk [block!] "Object words and values."
][
    make object! blk
]]

因此,对于object,对象是由一个附加了none 的块构成的。这不会改变长度,或者,据我所知,添加任何东西。另一方面,对于context,对象是用传入的块构造的,原样。

为什么会有区别以及为什么context 不能只是object 的别名。

【问题讨论】:

    标签: constructor rebol rebol3


    【解决方案1】:

    向后兼容性。我们在 Rebol 中已经有一个 context 函数,它以特定的方式工作(不是初始化变量),但我们需要一个将变量初始化为 none 的函数,作为将对象创建为数据结构而不是代码容器时的便利函数。

    称它为object 是有道理的,因为这是类型名称,并且因为“上下文”实际上对于具有上下文敏感语义的语言中的对象来说是一个坏名称(对于这个词的更合适的含义) “语境”)。这确实导致了一些令人困惑的对话。由于 R3 现在有了模块,所以以前对 context 函数的大部分使用都被模块更好地覆盖了。保留context 主要是为了向后兼容。

    当前的object 函数几乎是我们尚未想到的更好的类型构造包装器的占位符。我们需要类似的东西,但它的行为可能需要一些细微的变化,我们会在更多使用时发现这些变化。一方面,它修改了它的规范块这一事实使得它对于递归或并发来说不是很安全。如果这能改进它,它可能最终会成为一个本地人,或者如果结果证明这是一个更好的方法,它可能会成为一个 construct 选项。

    结果证明是成功的一件事是使用不带感叹号的类型名称作为类型构造函数的名称。我们也将map 更改为这样,我们最终可能会为其他类型添加类似的构造函数,尽管大多数需要它们的人已经拥有它们。

    【讨论】:

    • 我仍然很好奇构造函数中是否需要append。为什么会在那里?
    • APPEND 让你写对象 [a: b:] 并且 'a 和 'b 被初始化为 NONE。
    猜你喜欢
    • 1970-01-01
    • 2019-02-01
    • 1970-01-01
    • 1970-01-01
    • 2012-03-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多