I guess it just depends on how you're using the framework. I personally have never found this need, the only time I can imagine wanting this would be for object serialization and I use ember-data, so that need is not relevant.

That said, if I did have this problem, I would start by using Ember.ObjectProxy and see how far that got me. Here is an example: http://emberjs.jsbin.com/kapenomivu/1/edit?js,output

generic function that iterates over an object's properties

this is what hasOwnProperty is for

feel free to use, Ember.keys which is more or less Object.keys

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

That said, if I did have this problem, I would start by using Ember.ObjectProxy and see how far that got me. Here is an example: http://emberjs.jsbin.com/kapenomivu/1/edit?js,output

I would likely recommend against this, why not just use the pojo directly?

@stefanpenner I think that's really a question for the OP. I guess I was assuming that he had a class that had computed properties/functions/observers/etc. I had not considered just iterating with Ember.keys, I thought that would include stuff from the class (I swear way back in the day it did), but was pleasantly surprised to find it didn't.

Just out of curiosity, why would you recommend against using Ember.ObjectProxy?

Edit: Just to clarify, the Ember.keys solution is far cleaner and gets my vote. Was just curious if you had any negative thoughts specifically around ObjectProxy.

There are a few strategies to extract the original "Hash" structure that was used to create the ember object (with or without modified values), my question was mostly about how often the general Ember.js community needs this. a .nativeCopy method would be really nice on Ember.Object but I appreciate the necessity to be extremely selective with API additions. Sometimes it makes sense to add a method that makes an extremely common operation more convenient and sometimes it doesn't. I get the feeling people do not run into this need as often as I do.

One concrete example, if you're curious, is using an Ember.Object to back a "Create New […]" form. Perhaps the create form is right below a list of items. If you use this.store.createRecord to create a blank model to back the form, it immediately adds a new item to the list above and fills out the values as you fill out the form. To avoid this I might create an Ember.Object to back the form, but then I have to get the values out one by one to pass to createRecord

One last reason I do this a lot is to create a deep copy since implementing Ember.Copyable is such a pain. I like the design of Ember.Copyable but a sane default/generic implementation would be really really nice.

The biggest reason for needing pojo's is for 3rd party library support. Datatables, jstree, etc. all expect plain javascript arrays and objects and will blow up with ember data structures.

@ccarterc like, e.g. localforage.setItem - it is PITA with Ember.Object
Faced with it today and had to put custom "escaper" for that.

Ran into this exact need today. As @ccarterc said, this is crucial for 3rd party libs that are expecting POJOs. It would be great to have an "official" method to do this.

I want the ability to work with a POJO, so I can send my object into a 3rd party vanilla JS library.

yes please - struggling with this now for a 3rd party api. my current workaround is to do getProperties for an object with an array of about 70 fields on it. this seems silly and having a function to do that would be great...