Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Restore the QuickOpen.basicMatchSort and friends #9747

Merged
merged 2 commits into from
Oct 30, 2014

Conversation

dangoor
Copy link
Contributor

@dangoor dangoor commented Oct 30, 2014

This change broke a few extensions. Looking at the fix, it seems that all QuickOpen plugins will
likely need these functions, so we may as well re-export them as we have been doing rather than
requiring the extensions to all add another import.

If we do decide to deprecate these later, we should do so with deprecation warnings (something we
weren't doing when these were moved to the StringMatch module).

Revert "Marked as deprecated by adobe/brackets#2462 in Sprint 19"

This reverts commit 49e08274a0bc9259d6dd94c03351e4c87bf570f9.

This change broke a few extensions. Looking at the fix, it seems that all QuickOpen plugins will
likely need these functions, so we may as well re-export them as we have been doing rather than
requiring the extensions to all add another import.

If we do decide to deprecate these later, we should do so with deprecation warnings (something we
weren't doing when these were moved to the StringMatch module).

Revert "Marked as deprecated by #2462 in Sprint 19"

This reverts commit 49e0827.
@JeffryBooher
Copy link
Contributor

LGTM

JeffryBooher added a commit that referenced this pull request Oct 30, 2014
Restore the QuickOpen.basicMatchSort and friends
@JeffryBooher JeffryBooher merged commit 7e5dff3 into master Oct 30, 2014
@JeffryBooher JeffryBooher deleted the dangoor/quickopen-exports branch October 30, 2014 16:22
@le717
Copy link
Contributor

le717 commented Oct 30, 2014

Sorry about this guys. :(

@dangoor
Copy link
Contributor Author

dangoor commented Oct 30, 2014

@le717 No problem. I can certainly see how something that appeared to be deprecated since sprint 19 should be safe to remove.

@le717
Copy link
Contributor

le717 commented Oct 30, 2014

@dangoor Would you like me to submit a PR marking these using DeprecationWarning for 1.1 or do they just need to be noted in a card for eventual removal?

@dangoor
Copy link
Contributor Author

dangoor commented Oct 30, 2014

@le717 No, I actually considered leaving these removed and decided to put them back because it made the extension code a bit uglier. So, I updated the comment to reflect that I think these should stay.

@le717
Copy link
Contributor

le717 commented Oct 30, 2014

Yea, that makes sense. However, since they are convenience exports, it probably should be noted somewhere there is a chance they might break later on (just as a general statement, not necessarily going to happen).

@dangoor
Copy link
Contributor Author

dangoor commented Oct 30, 2014

You could almost say that about any of our APIs... there's always a chance they can break later on. As much as possible, though, when we do decide to break them, we will try to put deprecation warnings on first.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants