Algo que eu acho muito contra-intuitivo sobre Ember é que você pode sobrescrever uma função de setter de propriedade computada (http://emberjs.com/#toc_computed-properties-setters ) com os argumentos paracreate(). Vejohttp://jsfiddle.net/zJQJw/2/

Eu encontrei a melhor solução para isso é chamarcreate().setProperties(properties) ao invés decreate(properties), mas isso parece uma pegadinha desnecessária para mim. Eu percebo que pode quebrar alguns aplicativos neste momento, mas você consideraria fazercreate() se comportar mais comosetProperties()?

Minha motivação para pedir isso é queinit() será chamado antessetProperties() ao usar ocreate().setProperties(properties) padronizar. Isso ainda não foi um grande problema, mas eu posso ver isso sendo indesejável em algumas situações. Este é um exemplo completamente inventado, mas talvez você possa ver em que estou chegando?http://jsfiddle.net/QJ8vX/2/

A única razão pela qual posso ver para manter o comportamento atual é fazer substituições específicas de instância dos métodos setter. Mas nesses casos você poderia facilmente fazerMyClass.extend({ overridenMethod: ... }).create(properties)

Uma mudança como essa seria considerada para o Ember 1.0? Ou eu só tenho a idéia errada sobre como o modelo de objeto do Ember deve funcionar?