Backbone: 添加 getter/setter 支持以扩展方法

有什么理由不能更好地写成person.fullName()所以你知道这是一个函数调用吗？

在 JS 中使用 getter 和 setter 在很大程度上是一个坏主意，它们违背了 Backbone 模型的核心思想之一。 我怀疑您会很快看到添加的支持。

最重要的是，这将与新的类语法部分对齐。 类语法中没有属性初始化器，甚至还没有任何规范，因此互操作将是一个问题。

他们违背了骨干模型的核心思想之一。

这是什么核心思想？

吸气剂也是 Backbone.Collection 中现有问题的部分解决方案model.idAttribute 。

花了几分钟尝试用不同的解决方案制作一个 jsperf：
http://jsperf.com/backbone-extend-with-define-property

这是什么核心思想？

在对象上设置和检索属性的想法应该是透明且合乎逻辑的。 您应该始终知道obj.prop = val除了设置该属性值（检索时同上）之外从不做任何事情，而我们应该使用函数来处理诸如计算属性和更改事件之类的事情。 这就是首先围绕attributes的get和set包装器方法的主要原因。

此外，getter 是对带有 model.idAttribute 的 Backbone.Collection 中现有问题的部分解决方案。

当前的_.result包装器对此不起作用的任何原因？ idAttribute可以是原语或函数。 这也通过modelId修复。

抱歉，我应该链接到我正在谈论的问题： https ://github.com/jashkenas/backbone/issues/3408

我提出这个主要是因为 Backbone 的类语法在很大程度上已经与 ES 类语法兼容，考虑到对咖啡脚本的增加支持，它们兼容似乎是合理的。

CoffeeScript 主要出于相同的原因不支持 setter 和 getter（从 https://github.com/jashkenas/coffeescript/pull/2902 开始，请查看那里的问题以获得一些背景）。 它们不应该成为支持 Backbone 对象作为类的障碍。

抱歉，我应该链接到我正在谈论的问题：#3408

提醒我？ 我很紧张地看到蝙蝠的连接。

此外，对extend的任何更改都必须在_.extend中完成，而不是在这里。 关闭作为一个wontfix。

出于同样的原因，CoffeeScript 不支持 setter 和 getter

我不是在谈论 getter/setter，我是在谈论 Backbone 如何为与 CoffeeScript 的互操作添加__super__ ，以及它如何以同样的方式支持 ES6 类才有意义。

提醒我？ 我很紧张地看到蝙蝠的连接。

Collection.extend({
  model: function() { return Model }
});
//
collection.modelId(model); // 'id' regardless if that's correct or not.

Collection.extend({
  get model() { return Model }
});
//
collection.modelId(model); // correct for *some* of the common cases.

此外，对扩展的任何更改都必须在 _.extend 中完成，而不是在这里。 关闭作为一个wontfix。

这绝对不是进行此更改的正确位置，如果有的话，它会出现在新的_.assign方法中。 但是在IMO这里得到支持更有意义。

此外，在这个问题被关闭并被遗忘之前，我想解决为什么 Backbone 的扩展可以与 ES 类而不是 CoffeeScript 类的互操作问题。

好吧，因为 IE Tech Preview 是唯一一个支持class的浏览器（甚至 Traceur 和 6to5 还没有转换extends ），我们离这个还有很长的路要走必要的。 除此之外，Backbone 不会为了支持一开始就不是一个好主意的功能而特意打破向后兼容性。

甚至 Traceur 和 6to5 还没有转换extends

他们实际上都这样做了，他们只需要支持__proto__来获得广泛支持的静态属性。

此外，没有理由需要破坏 backwords-compatibility，如果它有选择地使用Object.setPrototypeOf ，它甚至可以变得更快。

@thejameskyle想把它变成 PR 而不是问题？ 值得一看。

当然，我会这样做

是在路上吗？ 你有什么要点吗？ 我想拍一张。