在脚本化的browser-plugin中处理只读/只写属性的最佳方法

Question

编写一个可通过JavaScript编写脚本的可嵌入式跨浏览器插件我不确定如何以最佳方式处理只读和只写属性。

更常见或更直观

• 在写入时以无提示方式丢弃值以及
• 返回只写的虚拟值

或

• 表示浏览器失败，最有可能导致脚本错误

建议？或者像Flash这样的广泛插件有什么好的例子吗？

更新
我不感兴趣，只写的属性是否有用 - 我不喜欢这个想法，但我必须支持这一点，因为历史原因。

Answer 1

现有的做法遵循Postel's Law：“你要保守自己的行为;要接受别人的自由。”

在这种情况下，这意味着您的插件的文档应该显示正确的用法，但它应该容忍使用不当。通过研究HTML与之前或之后发明的所有其他超文本系统的成功，这种方法的智慧应该是显而易见的。大多数失败都是束缚和纪律风格的设计，其中最小的错误导致文档无法读取。

正如人们经常编写错误的HTML一样，你的一些用户可能会传递错误的输入。假设您有一个布尔属性，记录为“true”或“false”。如果你得到1或0怎么办？它应该崩溃，还是应对？ Postel的法律说，应对。如果你得到-1怎么办？再次，应对，例如通过选择使用C的规则，非零是“真实的”。得到你的具体问题，如果将布尔属性记录为只读，有人给它一个值，你的插件就应该吃它。

所有这些特殊情况处理意味着为您提供更多编码，但使您的插件更易于使用，因此更受欢迎。

Postel定律的另一半意味着只读属性应该只有文档值。再次，采用布尔属性的情况：如果您的文档说值为“true”或“false”，则永远不要返回“1”，即使JavaScript理解这是一个真值。遵循您自己的规范，即使您编写的代码可以让其他人违反它而不受惩罚。

顺便说一下，我不喜欢只写属性的想法。你应该改变这些功能。那就是：

pluginInstance.setWriteOnlyProperty(5);

不

pluginInstance.writeOnlyProperty = 5;

只读变量是很容易理解的东西。只写变量很少见。我见过的唯一一次是在8位微控制器中，由于硬件设计，它的原因很明显。我没有在软件中找到这么好的借口的空间。

Answer 2

我不会默默地丢弃价值观，即使你在文档中说得很清楚。声明不返回任何类型的错误使它看起来应该有效。如果您收到明确的错误消息（“属性x是只读的”），则更容易调试。

但是，我同意Warren Young的回答，就只写功能而言。只写属性不直观。