#54 introduces behavior difference depending on Ember version

[SaladFork]

In #54, a shim was added for ember-platform/assign which will use Ember.assign if available (≥ 2.5.0) and Ember.merge otherwise. These do not have the same method footprint/behavior so could be a concern.

Ember.assign({}, {foo: 3}, {bar: 5})
// -> Object {foo: 3, bar: 5}

Ember.merge({}, {foo: 3}, {bar: 5})
// -> Object {foo: 3}

[rwjblue]

yeah, the issue is that we already used the named export of assign. Leaving import { assign } from 'ember-platform'; as always stuck to be a two arg situation is pretty crappy.

Do you have a specific scenario that breaks?

[SaladFork]

No, and I don't think it's too big a problem. Unless I'm mistaken you'd have to be downgrading Ember to run into this, as you'd have to be using assign with >2 arguments and going to an environment where Ember.assign is no longer available.

[rwjblue]

Right. One option I had thought of was to just include the shim directly so that assign always "just worked" with arbitrary args. But we generally don't want this repo to include "code"...

[john-kurkowski]

It'd be a breaking change to this lib, but would it otherwise hurt to export both?

They're not perfectly interchangeable. When Ember added it, they didn't claim assign to be a replacement. Neither is deprecated.

[rwjblue]

FWIW, Ember.merge was definitely deprecated when we added the Ember.assign feature. There were many issues with the deprecation being extremely noisy in the ecosystem, so we disabled the deprecation for 2.5.1 (see CHANGELOG.md or PR disabling the deprecation).

[john-kurkowski]

Ah, interesting. I only looked at the latest API docs. Thank you for the clarification.

[Turbo87]

closing due to inactivity