ramda源码中@@functional/placeholder是什么意思?
what 's the meaning of @@functional/placeholder in ramda source code?
我在 ramda 源代码中找到了@@functional/placeholder。
export default function _isPlaceholder(a) {
return a != null &&
typeof a === 'object' &&
a['@@functional/placeholder'] === true;
}
ECMAScript 标准中似乎没有'@'符号,那么这个符号代表什么?
这很奇怪。我从未见过这种用法,我想知道这是什么。
它只是一个对象上的 属性。它没有特殊的含义,除了 ramda 赋予它的含义。在 ramda 中,具有这个 属性 的对象是 R.__,这是一个特殊的对象,它只是告诉 ramda 的 curry 函数忽略这个参数(参见 documentation for __)。
对象属性的键可以是任何字符串或符号,他们选择字符串“@@functional/placeholder”是为了避免意外的名称冲突(极不可能有人会选择 属性 不小心起的名字)。
const example = {
'@@functional/placeholder': true,
};
console.log(isPlaceholder(example));
function isPlaceholder(a) {
return a != null &&
typeof a === 'object' &&
a['@@functional/placeholder'] === true;
}
(这里是 Ramda 作者)
Bergi 的评论和 Nicholas Tower 的回答都是正确的。这只是一个唯一的标识符,以确保您实际上不会传递一些可能被 Ramda 误认为占位符的有意义的东西。命名的直接灵感来自 transducer protocol,而后者又会受到著名符号 hack 的启发。
When this was chosen, we hoped that others doing functional libraries might use the same thing, for interoperability.虽然这从未发生过,但它似乎仍然是比其他选择更好的选择:我们不能选择使用 Symbol,因为我们支持 ES5 甚至 ES3。我们本可以选择使用库本身作为占位符,就像 lodash 那样,但这确实有意义,因为 lodash (_
) 看起来 的标准命名来自其他语言的占位符。或者我们可以只使用任意对象,但这需要我们通过引用进行测试,这在函数库中感觉很奇怪。或者我们可以只使用 undefined
作为信号,但这不允许有人实际使用 undefined
作为值。
所以我们最终制定了一个没有其他人遵循的标准,但它至少易于使用并且 Javascript 用户有点熟悉。
我在 ramda 源代码中找到了@@functional/placeholder。
export default function _isPlaceholder(a) {
return a != null &&
typeof a === 'object' &&
a['@@functional/placeholder'] === true;
}
ECMAScript 标准中似乎没有'@'符号,那么这个符号代表什么?
这很奇怪。我从未见过这种用法,我想知道这是什么。
它只是一个对象上的 属性。它没有特殊的含义,除了 ramda 赋予它的含义。在 ramda 中,具有这个 属性 的对象是 R.__,这是一个特殊的对象,它只是告诉 ramda 的 curry 函数忽略这个参数(参见 documentation for __)。
对象属性的键可以是任何字符串或符号,他们选择字符串“@@functional/placeholder”是为了避免意外的名称冲突(极不可能有人会选择 属性 不小心起的名字)。
const example = {
'@@functional/placeholder': true,
};
console.log(isPlaceholder(example));
function isPlaceholder(a) {
return a != null &&
typeof a === 'object' &&
a['@@functional/placeholder'] === true;
}
(这里是 Ramda 作者)
Bergi 的评论和 Nicholas Tower 的回答都是正确的。这只是一个唯一的标识符,以确保您实际上不会传递一些可能被 Ramda 误认为占位符的有意义的东西。命名的直接灵感来自 transducer protocol,而后者又会受到著名符号 hack 的启发。
When this was chosen, we hoped that others doing functional libraries might use the same thing, for interoperability.虽然这从未发生过,但它似乎仍然是比其他选择更好的选择:我们不能选择使用 Symbol,因为我们支持 ES5 甚至 ES3。我们本可以选择使用库本身作为占位符,就像 lodash 那样,但这确实有意义,因为 lodash (_
) 看起来 的标准命名来自其他语言的占位符。或者我们可以只使用任意对象,但这需要我们通过引用进行测试,这在函数库中感觉很奇怪。或者我们可以只使用 undefined
作为信号,但这不允许有人实际使用 undefined
作为值。
所以我们最终制定了一个没有其他人遵循的标准,但它至少易于使用并且 Javascript 用户有点熟悉。