Backbone: Getter/Setter-Unterstützung hinzugefügt, um Methode zu erweitern

Gibt es einen Grund, der nicht besser als person.fullName() geschrieben werden könnte, damit Sie wissen, dass es sich um einen Funktionsaufruf handelt?

Die Verwendung von Gettern und Settern ist in JS größtenteils eine schlechte Idee und widerspricht einer der Kernideen von Backbone-Modellen. Ich bezweifle, dass in absehbarer Zeit Unterstützung hinzugefügt wird.

Dies würde vor allem teilweise an der neuen Klassensyntax ausgerichtet werden. Es gibt noch keine Eigenschaftsinitialisierer in der Klassensyntax oder sogar irgendwelche Spezifikationen für sie, daher wird Interop ein Problem sein.

Sie widersprechen einer der Kernideen von Backbone-Modellen.

Welche Kernidee ist das?

Auch Getter sind eine Teillösung für ein bestehendes Problem in Backbone.Collection mit model.idAttribute .

Ich habe ein paar Minuten damit verbracht, ein jsperf mit verschiedenen Lösungen zu erstellen:
http://jsperf.com/backbone-extend-with-define-property

Welche Kernidee ist das?

Die Idee, dass das Festlegen und Abrufen einer Eigenschaft für ein Objekt transparent und logisch sein sollte, darüber nachzudenken. Sie sollten immer wissen, dass obj.prop = val niemals etwas anderes tut, als diesen Eigenschaftswert zu setzen (dasselbe gilt für das Abrufen), während wir Funktionen verwenden sollten, um Dinge wie berechnete Eigenschaften und Änderungsereignisse zu handhaben. Das ist überhaupt der Hauptgrund für die Wrapper-Methoden get und set um attributes herum.

Auch Getter sind eine Teillösung für ein bestehendes Problem in Backbone.Collection mit model.idAttribute.

Gibt es einen Grund, warum der aktuelle _.result -Wrapper dafür nicht funktioniert? idAttribute kann entweder ein Primitiv oder eine Funktion sein. Dies wird auch mit modelId behoben.

Entschuldigung, ich hätte auf das Problem verlinken sollen, über das ich gesprochen habe: https://github.com/jashkenas/backbone/issues/3408

Ich erwähne dies hauptsächlich, weil die Klassensyntax von Backbone weitgehend bereits mit der ES-Klassensyntax kompatibel ist, und es scheint nur vernünftig, dass sie kompatibel sind, wenn man die zusätzliche Unterstützung für Coffeescript berücksichtigt.

CoffeeScript unterstützt Setter und Getter größtenteils aus den gleichen Gründen nicht (sehen Sie sich die Probleme dort für Hintergrundinformationen an, beginnend mit https://github.com/jashkenas/coffeescript/pull/2902). Sie sollten kein Hindernis für die Unterstützung von Backbone-Objekten als Klassen darstellen.

Tut mir leid, ich hätte auf das Problem verlinken sollen, über das ich gesprochen habe: #3408

Erinnere mich? Ich bemühe mich, die Verbindung auf Anhieb zu sehen.

Außerdem müssten alle Änderungen an extend in _.extend vorgenommen werden, nicht hier. Schließen als wontfix.

CoffeeScript unterstützt Setter und Getter größtenteils aus den gleichen Gründen nicht

Ich habe nicht über Getter/Setter gesprochen, ich habe darüber gesprochen, wie Backbone __super__ für die Interoperabilität mit CoffeeScript hinzugefügt hat und dass es nur sinnvoll ist, ES6-Klassen auf die gleiche Weise zu unterstützen.

Erinnere mich? Ich bemühe mich, die Verbindung auf Anhieb zu sehen.

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.

Außerdem müssten alle zu erweiternden Änderungen in _.extend vorgenommen werden, nicht hier. Schließen als wontfix.

Das ist definitiv nicht der richtige Ort für diese Änderung, wenn überhaupt, wäre es in der neuen Methode _.assign . Aber es macht viel mehr Sinn, dass es hier IMO unterstützt wird.

Bevor dieses Problem geschlossen und vergessen wird, möchte ich außerdem ansprechen, warum es in Ordnung ist, dass die Erweiterung von Backbone Interop-Probleme mit ES-Klassen, aber nicht mit CoffeeScript-Klassen hat.

Da IE Tech Preview der einzige Browser ist, der class auch nur annähernd anständig unterstützt (selbst Traceur und 6to5 konvertieren extends noch nicht), sind wir davon weit entfernt notwendig. Abgesehen davon wird Backbone sich nicht die Mühe machen, die Abwärtskompatibilität zu brechen, nur um eine Funktion zu unterstützen, die von Anfang an keine gute Idee ist.

selbst Traceur und 6to5 konvertieren extends noch nicht

Sie beide tun es tatsächlich, sie benötigen nur Unterstützung für __proto__ für statische Eigenschaften, die weithin unterstützt werden.

Es gibt auch keinen Grund, die Backwords-Kompatibilität zu brechen, sie könnte sogar schneller gemacht werden, wenn sie selektiv Object.setPrototypeOf verwendet, wo verfügbar.

@thejameskyle Willst du dies in eine PR statt in ein Problem verwandeln? Anschauen lohnt sich.

Klar, das mache ich

Ist es unterwegs? Hast du eine Kernaussage oder etwas darüber? Ich möchte einen Schuss machen.