Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FIXES #14405] deprecation of enumerable events: #14710

Closed
wants to merge 1 commit into from

Conversation

stefanpenner
Copy link
Member

@stefanpenner stefanpenner commented Dec 11, 2016

deprecate:

  • addEnumerableObserver
  • removeEnumerableObserver
  • hasEnumerableObserver
  • hasArrayObserver

Remaining tasks:

  • come up with an implementation to deprecate without causing lots of spew.
    this is tricky, because we both depend on this method, and invoke it internally (as sometimes our way of enabling the public API)

  • deprecate all pieces

  • make tests green

  • ???

Questions:

  • deprecate until when?
  • we may also want to deprecate other mechanisms of subscribing to enumerable:change
  • do we create a internal methods (via private symbol) that enables un-deprecated internal usage?

* addEnumerableObserver
* removeEnumerableObserver
* hasEnumerableObserver
deprecate(
'Usage of `Enumerable.prototype.addEnumerableObserver` is deprecated.',
false,
{ until: '2.12.0', id: 'ember-metal.enumerable.addEnumerableObserver' }
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mixonic / @chancancode what is the appropriate until value here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can never remember; does 2.12 mean 2.12 is the last version where this continues to work? I'll have to update my patch accordingly.

@stefanpenner
Copy link
Member Author

@rwjblue may want to chat with you about this one sometime this week. Maybe tue or wed?

@chancancode
Copy link
Member

Is this also deprecating the hasArrayObserver property, or do we need to track that separately?

@stefanpenner
Copy link
Member Author

@chancancode oops, i can add that.

@chancancode
Copy link
Member

come up with an implementation to deprecate without causing lots of spew. this is tricky, because we both depend on this method, and invoke it internally (as sometimes our way of enabling the public API)

@stefanpenner not sure if it applies here, but in the past we have done something like this:

export actuallyDoFoo(instance, args) {
  // ... no deprecation... use this for internal uses
}

export default SomeClass.extends({
  doFoo(args) {
    deprecate(...);
    return actuallyDoFoo(this, args);
  }
});

@stefanpenner
Copy link
Member Author

stefanpenner commented Dec 14, 2016

@chancancode ya, that partially works. We will need to adapt some more as actuallyDoFoo if defined is a public API that we must invoke (and deprecate).

Basically we may need to add another level of indirection to correctly deprecate only users use of this, but not our own internal use of it.

export actuallyDoFoo(instance, args) {
  // ... no deprecation... use this for internal uses
}

export default SomeClass.extends({
  doFoo(args) {
    deprecate(...);
    if (this.actuallyDoFoo) { // deprecate } else { actuallyDoFoo(this, args); }
  }
});

@krisselden
Copy link
Contributor

where are these used internally that would cause spew?

@mmun
Copy link
Member

mmun commented Feb 21, 2018

Enumerable events were removed in #16116. hasArrayObserver is still around but we can add a deprecation for that separately.

@mmun mmun closed this Feb 21, 2018
@mmun mmun deleted the deprecate-enumerable-events branch February 21, 2018 06:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants