¿Por qué los argumentos para crear () se comportan más como setProperties ()?

Algo que me parece muy poco intuitivo acerca de Ember es que puede sobrescribir las funciones del establecedor de propiedades computadas (http://emberjs.com/#toc_computed-properties-setters ) con los argumentos paracreate(). Verhttp://jsfiddle.net/zJQJw/2/

He encontrado la mejor solución para esto es llamarcreate().setProperties(properties) en lugar decreate(properties), pero esto me parece una innecesaria trampa para mi. Me doy cuenta de que podría romper algunas aplicaciones en este punto, pero ¿consideraría hacercreate() comportarse más comosetProperties()?

Mi motivación para pedir esto es queinit() será llamado antessetProperties() cuando se usa elcreate().setProperties(properties) modelo. Esto no ha sido un gran problema todavía, pero puedo ver que esto es indeseable en algunas situaciones. Este es un ejemplo completamente artificial, pero tal vez puedas ver a qué me refiero.http://jsfiddle.net/QJ8vX/2/

La única razón que puedo ver para mantener el comportamiento actual es hacer anulaciones específicas de la instancia de los métodos de establecimiento. Pero en esos casos podrías hacer fácilmenteMyClass.extend({ overridenMethod: ... }).create(properties)

¿Se consideraría un cambio como este para Ember 1.0? ¿O simplemente tengo una idea equivocada sobre cómo debería funcionar el modelo de objetos de Ember?

Respuestas a la pregunta(2)

Su respuesta a la pregunta