Acho que depende apenas de como você está usando a estrutura. Eu pessoalmente nunca encontrei essa necessidade, a única vez que posso imaginar querer isso seria para serialização de objetos e eu uso ember-data, então essa necessidade não é relevante.

Dito isso, se eu tivesse esse problema, começaria usando Ember.ObjectProxy e veria até onde isso me levaria. Aqui está um exemplo: http://emberjs.jsbin.com/kapenomivu/1/edit?js , output

função genérica que itera sobre as propriedades de um objeto

é para isso que serve hasOwnProperty

sinta-se à vontade para usar, Ember.keys que é mais ou menos Object.keys

Ember.keys(Ember.Object.create({ foo: 1 }))
>  [ 'foo' ]

Dito isso, se eu tivesse esse problema, começaria usando o Ember.ObjectProxy e veria até onde isso me levaria. Aqui está um exemplo: http://emberjs.jsbin.com/kapenomivu/1/edit?js , output

Eu provavelmente não recomendaria isso, por que não usar pojo diretamente?

@stefanpenner Acho que essa é realmente uma pergunta para o OP. Acho que estava assumindo que ele tinha uma classe que calculava propriedades / funções / observadores / etc. Eu não havia considerado apenas iterar com Ember.keys , pensei que incluiria coisas da classe (eu juro que antes isso acontecia), mas fiquei agradavelmente surpreso ao descobrir que não.

Só por curiosidade, por que você não recomendaria o uso de Ember.ObjectProxy ?

Edit: Só para esclarecer, a solução Ember.keys é muito mais limpa e recebe meu voto. Só estava curioso para saber se você teve algum pensamento negativo especificamente sobre ObjectProxy .

Existem algumas estratégias para extrair a estrutura "Hash" original que foi usada para criar o objeto ember (com ou sem valores modificados), minha pergunta era principalmente sobre a frequência com que a comunidade Ember.js em geral precisa disso. um método .nativeCopy seria muito bom em Ember.Object mas aprecio a necessidade de ser extremamente seletivo com adições de API. Às vezes, faz sentido adicionar um método que torna uma operação extremamente comum mais conveniente e às vezes não. Tenho a sensação de que as pessoas não atendem a essa necessidade com tanta frequência quanto eu.

Um exemplo concreto, se você estiver curioso, é usar um Ember.Object para apoiar um formulário "Criar Novo […]". Talvez o formulário de criação esteja logo abaixo de uma lista de itens. Se você usar this.store.createRecord para criar um modelo em branco para apoiar o formulário, ele imediatamente adiciona um novo item à lista acima e preenche os valores conforme você preenche o formulário. Para evitar isso, posso criar um Ember.Object para apoiar o formulário, mas preciso retirar os valores um por um para passar para createRecord

Uma última razão pela qual faço muito isso é para criar uma cópia profunda, já que implementar Ember.Copyable é uma dor de cabeça. Eu gosto do design de Ember.Copyable mas uma implementação padrão / genérica sensata seria realmente muito boa.

A maior razão para a necessidade do pojo é para suporte de biblioteca de terceiros. Datatables, jstree, etc. todos esperam arrays e objetos javascript simples e explodirão com estruturas de dados ember.

@ccarterc como, por exemplo, localforage.setItem - é PITA com Ember.Object
Enfrentei isso hoje e tive que colocar "escaper" customizado para isso.

Encontrei exatamente essa necessidade hoje. Como @ccarterc disse, isso é crucial para bibliotecas de terceiros que estão esperando POJOs. Seria ótimo ter um método "oficial" para fazer isso.

Quero a capacidade de trabalhar com um POJO, para que possa enviar meu objeto para uma biblioteca JS vanilla de terceiros.

sim, por favor - lutando com isso agora para uma API de terceiros. minha solução alternativa atual é fazer getProperties para um objeto com uma matriz de cerca de 70 campos nele. isso parece bobo e ter uma função para fazer isso seria ótimo ...