Compute more statuses from BCD, using compute_from as needed #1327

foolip · 2024-07-05T13:20:34Z

No description provided.

foolip

Self-review to make this easier to check for others.

foolip · 2024-07-05T13:25:09Z

features/array-copywithin.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2015-09-30


This is a change from the previous 2016-09-20, but I think this is the right thing to do for consistency. The other array features matched Array, not TypedArray, if both were part of the feature. See below.

foolip · 2024-07-05T13:26:00Z

features/array-fill.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2015-09-01


Date and versions matches previous status override.

foolip · 2024-07-05T13:26:17Z

features/array-find.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2015-09-01


Date and versions matches previous status override.

foolip · 2024-07-05T13:28:35Z

features/array-iterators.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2016-09-20


Date and versions matches previous status override.

foolip · 2024-07-05T13:39:43Z

features/array-from.yml.dist

  baseline: high
-  baseline_low_date: 2016-09-20
-  baseline_high_date: 2019-03-20
+  baseline_low_date: 2015-09-30


Existing dist file, I added compute_from to apply a consistent approach, and it changes the Baseline low date.

foolip · 2024-07-05T13:49:15Z

features/promise.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2015-07-29


foolip · 2024-07-05T13:50:29Z

features/shadow-dom.yml.dist

+  baseline_low_date: 2020-01-15
+  baseline_high_date: 2022-07-15
+  support:
+    chrome: "53"


This changed slightly but now matches https://caniuse.com/shadowdomv1. Ditto for Safari below.

foolip · 2024-07-05T13:52:59Z

features/typed-array-iteration-methods.yml.dist

+    chrome: "45"
+    chrome_android: "45"
+    edge: "12"
+    firefox: "38"


Firefox and Safari versions changed, and Baseline low date too as a result. That seems OK in this case because filter() and friends feel like they're on equal footing with every() and friends that shipped slightly earlier.

Validating to see cases where we're not reaching from compute_from. 👍

foolip · 2024-07-05T13:56:14Z

features/typed-array-iterators.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2016-09-20


Unchanged due to compute_from: javascript.builtins.TypedArray.@@iterator, but notably the description points to entries() and including that would change the status. It would be good to handle this and array-iterators.yml in the same way, however.

The description really strongly implies we're treating those things as core to the feature. Either the description needs to change, or we need to bring entries() along for the ride. Feels more honest to do the latter, to change the status rather than reshape the feature.

foolip · 2024-07-05T14:00:34Z

features/typed-arrays.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2015-07-29


This is unchanged and matches https://caniuse.com/typedarrays except for Safari, where caniuse says that Safari 5.1 didn't support Float64Array. I haven't checked if that's right.

foolip · 2024-07-05T14:01:46Z

@Elchi3 can you review this? There are quite a few per-feature decisions for JavaScript here, and I tried to be consistent. But consistency sometimes leads to weird places. I think it's OK, but am happy to change whatever you think isn't optimal.

ddbeck

I'm OK with pretty much all of this, but leaving unmerged for Florian's review.

ddbeck · 2024-07-08T12:54:04Z

features/typed-array-iteration-methods.yml.dist

+    chrome: "45"
+    chrome_android: "45"
+    edge: "12"
+    firefox: "38"


Validating to see cases where we're not reaching from compute_from. 👍

ddbeck · 2024-07-08T13:01:21Z

features/typed-array-iterators.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2016-09-20


The description really strongly implies we're treating those things as core to the feature. Either the description needs to change, or we need to bring entries() along for the ride. Feels more honest to do the latter, to change the status rather than reshape the feature.

Elchi3 · 2024-07-09T09:41:07Z

@Elchi3 can you review this? There are quite a few per-feature decisions for JavaScript here, and I tried to be consistent. But consistency sometimes leads to weird places. I think it's OK, but am happy to change whatever you think isn't optimal.

I checked the JavaScript features and it is great to see values computed from BCD directly. LGTM to remove all the manual overrides.

I'm not sure I understand why certain JS features use compute_from. Taking into account all features feels more honest to me. Can you elaborate why is compute_from is useful here?

foolip · 2024-07-09T10:49:41Z

I'm not sure I understand why certain JS features use compute_from. Taking into account all features feels more honest to me. Can you elaborate why is compute_from is useful here?

I wanted to apply a consistent rule and at the same time minimize changes, and using compute_from to exclude typed arrays was the rule that resulted in the fewest changes.

I've now pushed another commit dropping all use of compute_from for JavaScript features and so you can review that instead. If you prefer it, it's fine with me too.

Elchi3

LGTM. I think my rule would be that not using compute_from is the default. If using it, it would be good to provide a reason.

foolip

I've commented on which Baseline low dates have changed now that compute_from isn't used. The noteworthy changes are:

Array iterators changed from 2016 to 2018 because of Array values() in Firefox 60. That data came from mdn/browser-compat-data#1014 and seems reliable.
Typed arrays changed from 2015 to 2017. I find this change to be unreasonable because typed arrays are usable without most of the methods. I'll put compute_from back.

foolip · 2024-07-09T10:50:37Z

features/array-fill.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2016-09-20


Was previously 2015-09-01

foolip · 2024-07-09T10:50:45Z

features/array-find.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2016-09-20


Was previously 2015-09-01

foolip · 2024-07-09T10:51:13Z

features/array-iterators.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2018-05-09


Was previously 2016-09-20

foolip · 2024-07-09T10:51:55Z

features/typed-array-iteration-methods.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2016-09-20


Was previously 2016-03-21

foolip · 2024-07-09T10:52:38Z

features/typed-arrays.yml.dist

+
+status:
+  baseline: high
+  baseline_low_date: 2017-08-08


Was previously 2015-07-29

foolip · 2024-07-09T11:05:29Z

LGTM. I think my rule would be that not using compute_from is the default. If using it, it would be good to provide a reason.

Can you review again after the typed array change?

I think that with how we're authoring most features, compute_from will end up being used in the majority of features. This is because most features are usable when they first ship, and still get some additional bits of API over time that are part of the feature and not worth splitting into a separate feature, at least not long term.

#1091 is a good example of this unfolding. It would be good to give some guidance on this in #1330 too.

Elchi3 · 2024-07-09T12:02:53Z

Can you review again after the typed array change?

I think this works for me. Take my comments as thoughts as I'm learning about compute_from and not as a blocker.

I think that with how we're authoring most features, compute_from will end up being used in the majority of features. This is because most features are usable when they first ship, and still get some additional bits of API over time that are part of the feature and not worth splitting into a separate feature, at least not long term.

Interesting. I guess for typed arrays the alternative would be to have two groups:

"Initial typed arrays" with the constructors that you've now put in compute_from.
"ECMAScript 2015 typed arrays" containing the additional methods etc. that typed arrays gained once they were moved from their own Khronos spec to the ECMAScript spec.

So, I guess your point is that we don't need these two groups but instead just one group with all BCD keys and then compute_from does the baseline computation based on a subset of BCD keys.

It would be good to give some guidance on this in #1330 too.

Guidelines when to opt into compute_from and not into separate features would be appreciated.

#1091 is a good example of this unfolding.

Interesting to see compute_from with a single key in that PR. I would have expected all keys except json_static to be in compute_from. (or have something like ignored_keys: api.Response.json_static).

foolip · 2024-07-09T19:25:07Z

Interesting to see compute_from with a single key in that PR. I would have expected all keys except json_static to be in compute_from. (or have something like ignored_keys: api.Response.json_static).

@ddbeck and I have discussed this and he was initially also surprised by my minimal approach, but later came around to it. The model I have is that in order to pin a feature to its initial shape, we only need to list the entrypoints and anything additional that is necessary to use the feature at all. Anything that isn't strictly necessary is left out. The effect is the same as listing all of the things that shipped initially, but it's easier to find the right keys without reference to implementation status.

Regarding excluding keys instead, that would require a new exclusions every time a feature gains a small additional bit. To me, it seems like more work and much more likely that it will be overlooked in some case, leading to a change in the feature's Baseline low date.

github-actions bot added the feature definition Creating or defining new features or groups of features. label Jul 5, 2024

foolip force-pushed the more-dist branch 6 times, most recently from 08f5775 to eb8608b Compare July 5, 2024 13:58

foolip commented Jul 5, 2024

View reviewed changes

foolip marked this pull request as ready for review July 5, 2024 14:00

foolip requested a review from Elchi3 July 5, 2024 14:00

ddbeck approved these changes Jul 8, 2024

View reviewed changes

foolip added 2 commits July 9, 2024 12:47

Compute more statuses from BCD, using compute_from as needed

26984d6

Don't use compute_from for JavaScript features

08cedbb

foolip force-pushed the more-dist branch from eb8608b to 08cedbb Compare July 9, 2024 10:48

Elchi3 approved these changes Jul 9, 2024

View reviewed changes

foolip commented Jul 9, 2024

View reviewed changes

Pin typed arrays to the constructors

1cccabc

foolip merged commit 8deba1e into web-platform-dx:main Jul 9, 2024

Compute more statuses from BCD, using compute_from as needed #1327

Compute more statuses from BCD, using compute_from as needed #1327

Uh oh!

Conversation

foolip commented Jul 5, 2024

Uh oh!

foolip left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

foolip commented Jul 5, 2024

Uh oh!

ddbeck left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Elchi3 commented Jul 9, 2024

Uh oh!

foolip commented Jul 9, 2024

Uh oh!

Elchi3 left a comment

Choose a reason for hiding this comment

Uh oh!

foolip left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

foolip commented Jul 9, 2024

Uh oh!

Elchi3 commented Jul 9, 2024

Uh oh!

foolip commented Jul 9, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants