Warum verhalten sich die Argumente für create () nicht mehr wie setProperties ()?

Etwas, was ich an Ember sehr kontraintuitiv finde, ist, dass Sie berechnete Eigenschaften-Setter-Funktionen überschreiben können (http://emberjs.com/#toc_computed-properties-setters ) mit den Argumenten zucreate(). Sehenhttp://jsfiddle.net/zJQJw/2/

Ich habe die beste Lösung dafür gefunden, indem ich anrufecreate().setProperties(properties) anstattcreate(properties), aber das scheint mir eine unnötige Sache zu sein. Mir ist klar, dass es an dieser Stelle einige Apps kaputt machen könnte, aber würden Sie darüber nachdenken, dies zu tuncreate() benimm dich eher wiesetProperties()?

Meine Motivation, danach zu fragen, ist die folgendeinit() wird vorher angerufensetProperties() bei Verwendung dercreate().setProperties(properties) Muster. Dies war noch kein großes Problem, aber ich sehe, dass dies in einigen Situationen unerwünscht ist. Dies ist ein völlig durchdachtes Beispiel, aber vielleicht können Sie sehen, worauf ich hinaus will?http://jsfiddle.net/QJ8vX/2/

Der einzige Grund, warum ich das aktuelle Verhalten beibehalten kann, besteht darin, instanzspezifische Überschreibungen von Setter-Methoden durchzuführen. Aber in solchen Fällen könnte man es genauso leicht tunMyClass.extend({ overridenMethod: ... }).create(properties)

Würde eine solche Änderung für Ember 1.0 in Betracht gezogen? Oder habe ich nur eine falsche Vorstellung davon, wie Embers Objektmodell funktionieren soll?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage