4

一方では、次のようになります。

>> 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

4

1 に答える 1

3

下位互換性。Rebolには、特定の方法(変数の初期化ではない)で機能するcontext関数が既にありましたが、オブジェクトをコードコンテナーではなくデータ構造として作成する場合の便利な関数として、変数をnoneに初期化する関数が必要でした。

objectそれが型名であり、「コンテキスト」は実際には状況依存のセマンティクスを持つ言語のオブジェクトの一種の悪い名前であるため(「コンテキスト」という単語のより適切な意味のために)、それを呼び出すことは理にかなっています。それは本当にいくつかの紛らわしい会話につながります。R3には現在モジュールがあるため、これまでのcontext関数の使用法のほとんどはモジュールでカバーされています。保持contextすることは、ほとんどの場合、下位互換性のためです。

現在のobject関数は、まだ考えていない、より優れた型構築ラッパーのプレースホルダーです。そのようなものが必要ですが、必要な動作に微妙な変更があり、さらに使用することで発見できる可能性があります。一つには、それがそのスペックブロックを変更するという事実は、再帰や同時実行に対してあまり安全ではありません。それが改善されればネイティブとして、あるいはそれconstructがより良いアプローチであることが判明した場合はオプションとして終わる可能性があります。

成功したことの1つは、感嘆符のない型名を型構築関数の名前として使用することです。私たちはそれにも変更mapし、他のタイプにも同様のコンストラクターを追加することになるかもしれませんが、それらを必要とするほとんどのコンストラクターはすでにそれらを持っています。

于 2013-02-28T21:06:48.143 に答える