out of sync: PrivateFieldValues vs PrivateFieldDescriptors

[leobalter]

this repo is out of sync with the class fields proposal.

One here it uses PrivateFieldDescriptors while the other uses PrivateFieldValues. Other similar names follow the same issue.

A synchronization between both proposals supports comprehension of the intended usage.

I'm not sure if this is related to #40.

[littledan]

Thanks for filing this issue. I definitely want to keep the two proposals in sync.

The change here is deliberate, but maybe a bad idea: This proposal upgrades private elements from being simple values to being descriptors. The intention is that implementing only private fields doesn't require all of the descriptor logic.

My hope was that this spec updated all the appropriate locations so that it all makes sense. But maybe the stacking-diffs format is unclear.

Do you think I should switch the class fields proposal to use descriptors? Or maybe produce a single, unified spec document? I'm not sure how to present the semantics the most clearly.

[tjcrowder]

@littledan - FWIW, it seems clear enough to me, especially with the text currently at the top of the spec for this proposal:

This specification draft is phrased as a diff against the class fields proposal.

[leobalter]

FWIW, it seems clear enough to me, especially with the text currently at the top of the spec for this proposal

@tjcrowder I'm glad it just works for you. Unfortunately it created confusion for me and I'm not sure what's your goal here rather than just telling my PoV is invalid.

---

The change here is deliberate

@littledan I don't mind the change being only here, but it was unclear to me one is directly replacing the other as there is no explicit diff.

Honestly I'm overwhelmed to the fact we needed proposals depending on other proposals, it makes it a bit complex while I'm trying to map coverage from the class fields text that apply to the private-methods text, e.g.

Do you think I should switch the class fields proposal to use descriptors? Or maybe produce a single, unified spec document? I'm not sure how to present the semantics the most clearly.

You're offering more than one thing I'd like but they seem to be conflicting.

So please let me try to answer each one:

Do you think I should switch the class fields proposal to use descriptors?

This seems like the easiest approach to do here. class fields is introducing something that would change to something completely different in private-methods, including the abstraction name. The way things are going, I'd just do this change so the dependencies would be easier to map for the ongoing proposals, IMO.

Or maybe produce a single, unified spec document?

To be fairly honest, these proposals are still walking together. Maybe you can foresee the class fields landing first to the specs but I believe they are all so close to completion.

This option is nice for me, but I don't want to force you into a more difficult process to get consensus from the committee.

I'm not sure how to present the semantics the most clearly.

My real request is to just avoid much abstraction introduction and changes in between the proposals.

Maybe the abstractions I mentioned are the only making me struggle to map coverage for.

Thanks for the work getting these organized, @littledan

[tjcrowder]

@leobalter - My intention was purely to provide another PoV, not to claim yours was invalid.

[caiolima]

The three features will be proposed to be landed all together in tc39/ecma262#1668. Does this adequately resolve the issue?

[ljharb]

@caiolima it would be ideal (altho probably a lot of work) if all three repos were fully updated before they’re archived (which happens at stage 4). It’s pretty confusing that the PR differs in significant ways from the proposal repos themselves.

[caiolima]

@ljharb what do you think if we change those repos to point the PR as the source of truth? We can either use https://arai-a.github.io/ecma262-compare/?pr=1668 (once we are able to keep those links alive) or store current diff version that it generates somewhere and link to it. This would achieve the outcome we want on documentation side, and avoids manually coming back to the each repo to change diffs there.

[ljharb]

Ecma can't rely on any links it doesn't host staying alive, so that link isn't a reliable long term source.

I think that there needs to be at least one proposal repo that is the source of truth, and in this case, there's three. You could certainly archive 2 of them and point them to the 3rd, and then you'd be able to update just that one?

[littledan]

Sorry, how does Ecma enter into any of this? Ecma doesn't have any particular relationship with the tc39 GitHub org that I know of except that it tries to archive its contents. Maybe we could make sure that Ecma archives https://arai-a.github.io/ecma262-compare/?pr=1668 as well?

[ljharb]

That is indeed the relationship.

The way to do that would be for TC39 to host the project, but we'd also need to make sure that that view can function if github no longer exists. That tool is meant to aid in PR review; it seems very strange to me to be pushing for it to be the canonical proposal spec, which for every single other proposal is an ecmarkup file in the proposal's repo.