Make CoreObject rely more on ES2015 class features and interop better.

[krisselden]

No description provided.

[krisselden]

the last commit has more than is needed to workaround the issue.

all that is actually needed is DefaultResolver.create = function create(props) { return new this(props); };

For some reason props is becoming undefined when it hits the CoreObject.create intermittently in some test cases.

[rwjblue]

LGTM

I’d generally like to get a bug reported to the FF folks, but I think as long as we have that we can land. The current canary cycle is another few weeks and then we have a full beta cycle, which should be plenty time for a “shake down”...

[rwjblue]

I guess maybe we should also add another test (or few tests) to the ES compatibility test suite for things that wouldn't have worked before, but do work with these changes...

[DLiblik]

I've noticed that EmberObject.create(null) no longer works - was this intended? If not, I will open a separate issue. We had some code break as a result when we were initializing simplified objects.

[rwjblue]

@DLiblik - Hmm, I'm not sure I can reason about what that should have done. Feel free to open a new issue and we can discuss it (pretty likely to get lost as a comment on an old PR...).

[DLiblik]

@rwjblue Thanks - my understanding is that it creates an object without standard superclass properties - I think there's been a dialog over at #15001 (Drop EmptyObject and use Object.create(null) again). But it's not clear to me what the actual design decision was in either case - opening a new issue to discuss.