Coś, co wydaje mi się bardzo sprzeczne z intuicją w Ember, to zastąpienie obliczonych funkcji ustawiania właściwości (http://emberjs.com/#toc_computed-properties-setters ) z argumentami docreate(). Widziećhttp://jsfiddle.net/zJQJw/2/

Uważam, że najlepszym obejściem tego problemu jest zadzwonieniecreate().setProperties(properties) zamiastcreate(properties), ale to wydaje mi się niepotrzebne. Zdaję sobie sprawę, że w tym momencie może to spowodować przerwanie niektórych aplikacji, ale czy rozważasz ich wykonaniecreate() zachowuj się bardziej jaksetProperties()?

Moja motywacja do tego jest takainit() zostanie wywołany wcześniejsetProperties() podczas korzystania zcreate().setProperties(properties) wzór. Nie był to jeszcze duży problem, ale w niektórych sytuacjach widzę, że jest to niepożądane. Jest to całkowicie wymyślony przykład, ale może widzisz, co mam na myśli?http://jsfiddle.net/QJ8vX/2/

Jedynym powodem, dla którego mogę zachować obecne zachowanie, jest wykonanie specyficznych dla instancji przesłonięć metod ustawiających. Ale w takich przypadkach równie dobrze możesz to zrobićMyClass.extend({ overridenMethod: ... }).create(properties)

Czy taka zmiana byłaby rozważana dla Embera 1.0? A może mam zły pomysł na to, jak powinien działać model obiektu Embera?