Closed Bug 1716250 Opened 1 month ago Closed 1 month ago

Stop distinguishing between JS_FRIEND_API and JS_PUBLIC_API

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: tcampbell, Assigned: tcampbell)

Details

Attachments

(1 file)

The distinction between the two is largely historical now since we don't have any current policy about what types of changes are allowed to JS_PUBLIC_API. I propose we merge the two at this point. The js/public/experimental directory for headers seems like a better way to organize experimental APIs. This shouldn't have material impact other than being one less piece of tribal knowledge that we need to pass around.

(Bug 581271 is illustrative of how things were viewed in the old days..)

Convert all JS_FRIEND_API to JS_PUBLIC_API. At this point, the JS_PUBLIC_API has
no formal curation process and in practice we add a lot of new features to
JS_FRIEND_API without giving much thought to if they should be public. The
result is that all embedders need to use the friend API in some form and the
distinction has lost meaning.

Going forward, we should continue to use the js/public/experimental directory as
a place to expose new APIs, and in general should strive for high quality of the
APIs that are exposed. If a particular API is tricky or discouraged, comments
explaining that will be more helpful that a losely applied FRIEND_API marker.

Pushed by tcampbell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/36647ef6f014
Remove JS_FRIEND_API. r=jandem,sfink
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
You need to log in before you can comment on or make changes to this bug.