Community feedback

[Igmat]

I've written overview article (English version) for current proposal at the biggest portal for Russian-speaking developers yesterday.

Obviously, article is in Russian, so majority of you won't be able to read it, until I make a translation (it's in progress now).

But important thing is that I also organized a poll there, since habr uses invite system such poll is little bit more accurate, because users most likely have proper background to provide valuable feedback. And current result is:

What should be done with class-fields-proposal?	Total votes	%
Accept as is	3	2.7
Accept, but change [[Define]] semantic to [[Set]]	7	6.4
Accept, but tunnel private properties through Proxy	2	1.8
Accept, but tunnel private properties through Proxy, and change [[Define]] semantic to [[Set]]	6	5.5
Move to stage1/stage2 in order to solve existing problems and/or assess alternatives	32	29.3
Reject in favor of one of the alternatives	6	5.5
Reject fully, since we don't need neither public nor private fields	11	10
Separate into 2 proposal (public and private), where public part should be accepted and private should be reworked	42	38.5

Total views: more than 4700 Total voters: 109 Those who only interested in results: 35

In most cases duration of discussion around articles at this portal is one week, so in 7 days we'll have more accurate result (I expect that it will have at least 10k views, because my previous article was viewed more than 25k times) and I'll update this post.

But it seems that we can already say that community doesn't satisfied with current proposal.

[slikts]

The article doesn't even try to take a neutral stance (what the title translates to is "what went wrong in TC39"), so the answers are likely to be skewed in one direction, and even if the polling would somehow be statistically unbiased, it wouldn't add any new information, since it's already known that the proposal is controversial, which is a given for anything that breaks with familiarity.

[Igmat]

@slikts making a judgement basing only on title translation is not serious. While, it's not a 100% neutral (because it's just impossible) I tried to be as objective as possible. For example few translated quotes:

Despite all the above, I am not an irreconcilable opponent of the [[Define]] semantics (although I would prefer [[Set]]), because it has its own positive aspects.

All this stuff is related to syntax only, which means that subjective aesthetic opinion comes in play. In the end we could live with such syntax and get used to it.

It's very good - we could have hard-private , which can't be accessed/intercepted/tracked from outer code and at the same time we're even able to access privates of another instance of same class.

brand-check, actually, has its own use cases - in most cases they relate to secure execution of untrusted code in same process with possibility to share objects directly without serializing/deserializing overhead.

And there are more - please wait for translation before blaming me, because you already convinced few persons (@nicolo-ribaudo, @trotyl and @ccjmne) that this feedback is useless, which isn't true and leads to community breaks.

---

Article gives full overview of existing proposal with all its advantages, disadvantages and trad-offs. And, I haven't seen anything like this before.

Presentations from committee always avoid talking about trade-offs (like in existing README and FAQ), so community doesn't aware of ANY real problems behind it - from other side I did my best to be objective and cover all related things, including pros (mostly referring to existing docs/faq and justifying some committee decisions in comments) and cons without hiding problems under the carpet.

---

it wouldn't add any new information

I can't agree, because this poll shows that not only few active persons in this repo care about disadvantages of existing proposal, but rather much bigger part of community. And this part would rather wait for better solution, than live with half-backed feature.

P.S.

In my article I also raised important problem - lack of community feedback at early-stages. And, I personally will do my best to gather and provide such feedback for other proposals - but started from this one even though it's in stage3.

[slikts]

I can read Russian, the tone is editorial, you make your preference against the proposal clear, so it biases any outcome of the poll.

I can't agree, because this poll shows that not only few active persons in this repo care about disadvantages of existing proposal …

No one has claimed the opposite, and a negative outcome to polling is expected just based on the unfamiliarity of the syntax.

[Igmat]

negative outcome to polling is expected just based on the unfamiliarity of the syntax.

Repeating this again and again across threads doesn't make this statement true.

I and many others showed dozens of times that negative feedback ISN'T caused ONLY by syntax even though it obviously affected it.

[slikts]

It shouldn't need to be repeated that familiarity is a major factor in judgement. Everyone is closely familiar with syntax, while fewer people will have familiarity with decorators, and very few people will know what brands are in type systems. Negative reactions to changing familiar syntax for information hiding is completely predictable, and it was understood when the syntax was chosen as a compromise. Neither this poll nor the tallying of votes in #100 really add new information. What really matters are well-informed opinions, and that doesn't mean that they'll be uniform, if only because of human factors. The reason I keep repeating this is that it doesn't seem to be understood.

[Igmat]

@slikts it seems that you ignore the fact that syntax ISN'T major concern for most of the developers. When somebody (e.g. @littledan) presents this proposal, first reaction is "why #?", he answers why (repeating FAQ) and developers agree that it's ok - then committee decides that developers would be ok with proposal after getting used to new syntax. But developers AREN'T aware of other trade-offs (e.g. brand-check and [[Define]] semantic), because they just don't think about them and committee doesn't tell. My article tries to fulfill this gap.

Since, you mentioned that you can read Russian, and I start thinking that I haven't properly expressed my opinion, so you can understand it, I'll switch to Russian (everybody else, could ignore such part of comment, since it will be mostly paraphrasing of previous paragraph)

Я уже много раз писал, что, несмотря на факт того, что первая реакция - это непринятие синтаксиса, проблема намного глубже т.к. происходит приблизительно следующее:

1. Комитет презентует этот пропозал
2. Разработчики высказывают недовольство синтаксисом
3. Комитет его объясняет
4. Разработчки соглашаются с ними
5. Комитет решает, что всё ок и любой дальнейший фидбек не имеет смысла

Но это не так, разработчики могут СПОКОЙНО принять синтаксис. Но когда они узнают, что пропозал обладает СЕМАНТИКОЙ, которая ломает существующие юз кейсы и добавляет скрытые проблемы, они НЕ ХОТЯТ его принимать несмотря на другие преимущества, которые он даёт. Между ПЛОХОЕ + ХОРОШОЕ или НИЧЕГО они предпочитают НИЧЕГО. Моя статья описывает изменения в семантике, а опрос демонстрирует, что людям такие изменения НЕ НУЖНЫ. Игнор подобного фидбека комитетом это просто плевок в лицо комьюнити, мол "вы (комьюнити) ничего не понимаете и юз-кейсы ваши ничтожны, а мы (комитет) всё знаем намного лучше и наши юз-кейсы и планы намного важнее ваших".

[rdking]

@slikts I get your position, but you're a little stuck. Those of us who want to stall this proposal don't care so much about the syntax. Look at the poll. In that poll, they said they don't want to kill the proposal. Why do you think that is? We all want language support for private! And admittedly, despite the issues with it, this proposal provides that. We want that. We just don't want to break any of the many other things we can do just to get it!

I've been one of the biggest detractors of this proposal since I found out about it. As bad as the syntax is, if it didn't have all the semantic and functional problems, I'd gladly accept it without complaint. The problem is that this proposal interferes destructively with the existing language. That's what the people don't want. That's what this poll reflects. That's why TC39 should take heed.

[slikts]

@Igmat You're making my point about turning the discussion into polemics by using loaded language about "spitting in the community's face" and arguing against imagined scenarios where the flaws would be withheld.

@rdking The reason I'm "stuck" is because the numbers of votes keep being brought up as more meaningful than they are. For example, the meaning you're trying to read into this poll isn't even directly related to the questions asked; it's just what you want it to be. It would actually help your case more if you wouldn't grasp at every straw.

[rdking]

@slikts

The reason I'm "stuck" is because the numbers of votes keep being brought up as more meaningful than they are.

I don't understand in what way the community's opinion is not important. It's not the TC39 that will be the lion's share of developers using the results, but rather the community. Now let's be honest about something: ~90% of all ES developers don't have a clue how it works under the hood and could care less as long as their intuition about what should and shouldn't work pans out. Among the remaining, only about half of them have the confidence to express their opinions on this. This tracks with every community poll I've ever seen done about anything technical related to ES.

What does that matter?

• The voter turn-out over a non-filtered open poll tracks those numbers closely enough, lending them credibility.
• Those who voted have a high likelihood of having enough experience to understand the ramifications of this proposal on their projects and the libraries they import.
• The opinions of such developers should not be taken lightly as it is they who are most likely to either encourage or dissuade the use of any given language feature within their sphere of influence.

Put another way, the opinions of the community are what's going to make or break this proposal. If the community rejects it in large part, then the proposal will have been a failure even after reaching stage 4. Of course, there will always be those who use it because it's far simpler than the alternatives, but that doesn't make this a good for the community.

For example, the meaning you're trying to read into this poll isn't even directly related to the questions asked; it's just what you want it to be. It would actually help your case more if you wouldn't grasp at every straw.

I can't read Russian, so I'm basing my opinion on what's given in this thread. However, it looks to me like within the community that could understand @Igmat's article and decided to vote, there's an overwhelming consensus that this proposal needs to be re-worked. Few want to throw it away because there is a strong desire for language supported privacy, and this proposal is already so close, but it just isn't close enough. Tell me, what exactly am I reading into this that's not plainly obvious from the poll results?

[shannon]

@slikts Part of the problem is that the various polls and "votes" on this repo are submitted by the community because TC39 members have repeatedly stated that they do not consider votes to be an appropriate or even useful metric to measure this proposal. I can understand this.

However, the lack of information on the community feedback the TC39 did collect is troublesome. I see multiple comments from TC39 members on anecdotal and untracked conversations with "major frameworks, Node.js, large websites, etc". You yourself repeatedly state that the bulk of feedback has been about syntax when the vast majority of conversations I have been involved with in this proposal have less to do with the sigil/syntax and have been all about semantics and functionality and practical use cases.

Every time an alternative is suggested, the result is always, this isn't new, we already thought of that, and it won't work because this other obscure thing that someone said about proxies, or membranes, or something else that is not mentioned in the FAQ anywhere. It was suggested to me to read the TC39 notes to see some of this conversation. I haven't gone through it all but I see plenty in the last meeting notes to see that it is anything but unanimous that this proposal is the correct path. There are no indications of a "consensus" written in the notes. In fact the conclusion is clearly marked "?".

What other "major" frameworks were consulted? Were they presented with any alternatives? Were they presented with any of the trade-offs? What were their actual words on the matter? Right now the community has no visibility into this. Or at least it's very obscure. The constant feedback from the more advanced community on semantics and functionality in this repo over the last several months indicates to me that not everyone agrees with these "major" frameworks and websites of the TC39 members.

The end result is that I (and I assume others) feel like this process is not working. Say what you want about the proposal or the alternatives, people have every right to disagree on different things and everyone thinks they know best. Fine, but the process is not working.

[slikts]

Those who voted have a high likelihood of having enough experience to understand the ramifications of this proposal on their projects and the libraries they import.

This is a conjecture that doesn't even follow common sense. It takes no commitment to cast a vote in a poll, and it takes little commitment to leave a snippy comment about syntax. Meanwhile, the syntax being an universally familiar aspect of programming is a truism.

Tell me, what exactly am I reading into this that's not plainly obvious from the poll results?

Your interpretation of the motivations behind the votes isn't reflected in the questions. The questions are just about what to do, not why.

@shannon This is a thread specifically about votes and my remarks are in that context. Even though you say you understand why polling shouldn't dictate the design, you also seem to want to have it both ways and make the critics speak for "the community" based on the numbers. This actually detracts from the specific criticisms by taking away focus. I've personally grown weary of reading the long posts that amount to throwing things at the wall and seeing what sticks.

[shannon]

@slikts My point was that the community is trying to fill a gap that the TC39 process has (at least with this proposal). I don't think every vote/poll should be taken at face value and there are lots of biases that get added without even realizing. But in the absence of any other information it's even easier to read them incorrectly.

Framed correctly a questionnaire can be useful. Doing it correctly is hard but something a group of highly intelligent domain experts such as the TC39 committee should be able to achieve. If the process is really just let's ask the members of TC39 who happen to be the owners of major frameworks and large websites what they think and just go based on that. Well that's not community feedback, it's just committee feedback. It's not a democracy, I get it, but if that's the process then I don't think I really want to contribute to the process anymore and will just move on to something else.

[Igmat]

@slikts, we tried to focus on technical discussion with pros/cons of existing proposal and alternatives - it didn't work, because committee responded: it doesn't affect the majority, but only few active persons in this repo. Then I tried to get response from community, and you say that such poll doesn't make any sense.

So, what are you propose to do?

P.S.

The questions are just about what to do, not why.

They are formulated in way which allows us to easily understand reasons behind them.

[slikts]

What I propose you don't do is try to make this into the equivalent of a DoS attack, since it detracts from the actual technical points. If you insist on polling, look into topics like self-selection bias, since it's what a reliable polling methodology needs to control for.

[rdking]

@slikts

This is a conjecture that doesn't even follow common sense. It takes no commitment to cast a vote in a poll, and it takes little commitment to leave a snippy comment about syntax. Meanwhile, the syntax being an universally familiar aspect of programming is a truism.

Somehow, I think you would be thoroughly dumbfounded by how often it occurs that in a technical community, those with insufficient knowledge find themselves unwilling to voice their own opinion on an issue they feel they do not adequately understand. Does that follow common sense? No. You're right on that point, but there are a lot of things in life that don't follow common sense yet are none-the-less real.

Your interpretation of the motivations behind the votes isn't reflected in the questions. The questions are just about what to do, not why.

Ok. Then let's try rational analysis to see if my interpretations are truly not reflected. Let's treat this like a mystery. We have evidence (the poll) that a motivation exists, and decisions derived from that motivation.

So tell me, what potential motivations exist that would make the community ~5 times more favorable towards either splitting the proposal or back-staging it over simply rejecting it? I'm offering

• "a strong desire to gain some of the features of the proposal sooner rather than later".

Notice this makes no claims about whether or not the proposal is wanted at all?

Now tell me, what potential motivations are there for the community being ~20 times less likely to accept the proposal as is, and ~5 times less likely to accept the proposal with minor fixes, versus either splitting or back-staging the proposal? I'm offering

• "a strong desire to not pay the trade-offs that the current proposal demands"
• "a strong desire not to put up with the syntax the current proposal demands"

In all fairness, I have to offer both. However, given that @bakkot, @ljharb, & @littledan have all given testimony that an explanation of the syntax has been sufficient to make developers comfortable enough with the syntax, I find the second potential motivation significantly less likely.

So, if you truly believe that my "interpretation of the motivations behind the votes isn't reflected in the questions", then please present me with other possible motivations that are a better fit to the evidence. I've shown you how I derived my opinion. Show me how you derived yours.

[slikts]

Turning this into an existential discussion is what I mean by a DoS attack; I don't have time to unpack everything being said, so I'll just reiterate that the questions don't directly ask about motivations, so it's a matter of interpretation. A single leading article also won't turn people into domain experts, so they'll vote on what they know, which, for the most part, is syntax.

[rdking]

I don't see why you're talking about an existential discussion and DoS attacks, which have nothing to do with the arguments being made in this thread. Here's the summary again:

Out of all the people who felt confident enough voted on these issues:

• Only 3 out of 92 would choose to accept the proposal as is.
  • Regardless of their motivations, that's a pretty strong indication of a potential problem.
• Only 13 out of 92 would choose to accept the proposal with a small modification.
  • Put another way 13 out of 16 voters who would accept this proposal believes it needs at least some small modification.
• 76 out of 92 voters would rather see this proposal stopped, stalled, replaced, or split.
  • Infer what you will about motivation, but if that's any indication at all about how this proposal will be received by the public, this is not good news.
• Only 13 out of 76 voters who won't accept it even with a small modification would see this proposal rejected or replaced.
  • Again, infer what you will about motivations, but it looks like there is at least some desire to get these features released sooner rather than later.

If the goal of TC39 is to produce language features the majority of the community will want to use, then it should run polls of its own. Simply claiming that the will of the community is invalid or irrelevant is the same as saying that a business can stay alive indefinitely with little to no customers. Feel free to believe what you want, but it might be better not to refuse to see an inconvenient truth being put before you.

[slikts]

… which have nothing to do with the arguments being made in this thread.

As a courtesy you could try to understand what people take the time to say, especially since it's not with a rambling wall of text.

[rdking]

@slikts

As a courtesy you could try to understand what people take the time to say, especially since it's not with a rambling wall of text.

As a courtesy, I'll say this once. Nothing that @Igmat or I have said is a matter of existentialism, but rather a discourse of how TC39's dismissal of the developer community's opinion could have a negative impact on the future of ES. Nothing we have said is a "rambling wall of text", or an attempt to flood the threads with off-topic information such as to prevent the necessary communication required to advance the current proposal (DoS attack) either.

Your constant mischaracterization of other threads containing dissenting opinions, and your refusal to bother comprehending what's been said in this thread has helped me understand what value I should apply to your opinions. Thank you.

[littledan]

There is just a lot of text. It takes time to read it all. I am not really sure how anyone can keep up.

[rdking]

I get it, but I won't deign to comment on something I don't understand. What exists above is nothing more than an example of what happens when a community poll is given about this proposal, and conversation over why it would be beneficial for TC39 to do the same.

I'm not entirely certain anyone can keep up. When unread portions of the thread get long, I mostly speed read looking for the important parts.

[slikts]

There's minimal actual substance to keep up with; it's polling about things already known, asking for more polling about the same things, and doomsaying about what'll happen if polls aren't heeded; all padded in so many words that it takes too much time commitment to read and respond.

[mbrowne]

To @Igmat's point, it would be great to have more confidence in the community feedback collection process. There's very little visibility into how feedback is collected outside of this repo. I believe (based on comments in this repo) that the committee members are generally objective and interested in listening. So I'm guessing that on a spectrum of comprehensive and balanced to completely biased, it's on the better end of that spectrum. But just as a survey can give skewed results depending on how it's written and conducted, it's also possible that private feedback from big websites and library maintainers could be biased depending on how tradeoffs were presented, or whether known downsides of certain decisions were presented at all.

I don't know what could be done about this, since not all significant players in the industry will be interested in participating in public debates like the ones in this repo. I'll just say that I didn't find @littledan's comments in #151 very reassuring with regard to the Set vs Define issue. And even more importantly, I haven't seen any official consensus statement from the committee itself on this issue, explaining the technical reasons why they decided on Define, but only a few isolated comments in favor of it and a link to an earlier unsettled debate. It's great that the FAQ exists to explain the reasons for the syntax. I think it could be very helpful if there were a similar document explaining the most controversial semantic decisions.

[mbrowne]

@rdking The verbosity is indeed an issue, and sometimes I think it actually hurts your cause. I can relate because I struggle to be concise sometimes too, but it's well worth the effort especially in public forums like this. (And to the rest of you reading this, I'm aware that I'm posting 3 comments at once here and I assure you that I am trying to communicate as concisely as possible.) Some of your comments could have probably been parts of a larger blog post or document that you would link to for those who want more detailed explanation. I think your creation of the class members proposal has been a good thing in this regard because it has provided a place to go deeper into some issues without inundating the issue threads here.

[mbrowne]

@littledan On the other hand, I would also like to defend @rdking and others for repeating themselves in some cases. A lot of have it has arguably been unnecessarily verbose repetition, but there are a few sticking points to which the response from the committee has mostly been silence, and it's natural to repeat a question if it seems like it's being overlooked or disregarded. I sympathize with the committee because I know a herculean effort has gone into this proposal, including the community feedback process, and everyone has limited time. But I think it would really help the discussions here if the most controversial points other than the syntax (which has already been addressed a lot) were addressed more fully and formally by the committee, especially the request for a list of requirements for this proposal and the reasons for them.

[Igmat]

I finally translated my article, so you can read it in medium. I focused on trade-offs of this proposal, since they aren't covered anywhere outside of this github repo, so community feedback could be reasonable ONLY if responders are AWARE of limitations of this porposal and not only of advantages. I also updated first post in this thread with latest related info.

I hope that @littledan, @ljharb, @zenparsing or anybody else from @tc39 committee is able to assess this article, poll and its results for possible further impact on proposal.

[rdking]

@mbrowne I get the issue with me being verbose. I can be very terse when being concise, so it often leads to misunderstandings (mostly due to me thinking some concepts in my head are easy to understand when they're probably not), especially when dealing with a nuanced subject like language-internal details. That's the reason why I've been being verbose.

[DmitryOlkhovoi]

@Igmat I think fields should be setted in the prototype as methods. For now plugin-proposal-class-properties sets them in the constructor as an object property and I don't understand why. It looks inconsistent, could someone explain?

[mbrowne]

@DmitryOlkhovoi There's a major problem with that. Consider:

class Demo {
  // if this gets set to Demo.prototype.arr...
  arr = [1]
}

const d1 = new Demo()
const d2 = new Demo()
d1.arr.push(2);
console.log(d2.arr)  // [1,2] - the same array is shared across all instances!

[DmitryOlkhovoi]

@mbrowne Yes, but on the other hand we don't create the array every time. I understand the problem. But maybe then it should be called differently? Object fields? :)

[mbrowne]

@DmitryOlkhovoi I admit that when I first learned about this proposal, the name seemed like a misnomer to me. Historically if you used the term "class property" in an OOP language it probably referred to a property of the class itself, i.e. a static property. But on the other hand the name makes clear that these are fields within a class declaration. Currently this proposal does not include the ability to create private fields on objects not created by classes. So although the name isn't perfect, I'm fine with it. Disclaimer: I don't know if the committee's reason for choosing the name is the same as what I explained here; this is just my personal opinion. Anyway it seems rather late to rename it now.

[DmitryOlkhovoi]

@mbrowne Just to clarify my experiences:

class A {
    constructor() {
        this.setFoo();
    }
}

class B extends A {
    setFoo() {
        this.foo = 'Foo';
    }
}

// Works
console.log(new B().foo)

class AA {
    constructor() {
        this.bar = this.foo
    }
}

class BB extends AA {
    foo = 'Foo';
}

// Undefined
console.log(new BB().bar)

https://jsbin.com/qitizitifu/edit?js,console

[mbrowne]

I forgot to mention, this proposal originally included static fields as well (which have since been moved to a follow-on proposal). So that could have factored into the naming decision.

[mbrowne]

@DmitryOlkhovoi regarding your last comment, I think it's generally agreed that it's a bad design to write a base class whose functionality depends on a particular subclass, unless you're specific about it by using an abstract class or interface (so you'd need to find some workaround for such a design in JS since those features don't currently exist). Anyway the reason that bar is undefined in your second example has to do with timing: fields in subclasses are not defined until after calling super(). This is expected behavior according to the current proposal. Personally I'm fairly neutral on that issue. If you want to make a case for different behavior I suggest you start by searching this repo for past discussions about super() and when fields get created. Or perhaps someone else here who participated in those discussions can provide some direct links.

[DmitryOlkhovoi]

@mbrowne yes it looks like a bad design :) Have you ever heard about backbone.js? :)

. Anyway the reason that bar is undefined in your second example has to do with timing: fields in subclasses are not defined until after calling super().

This is because it's not in prototype, that is what I'm trying to say. Looks like it should be, just like methods

[ljharb]

@mbrowne static fields (both public and private) are not in a followon proposal, they are in the current one.

@DmitryOlkhovoi backbone’s design, and the bugs it caused, are strong evidence to not put data properties on the prototype. @jridgewell can speak to that in more detail.

[DmitryOlkhovoi]

@ljharb I understand potential bugs, but calling it Class fields and setting them as object own props feels a little bit confusing

[mbrowne]

@ljharb Ah, that's what I initially thought but then when I just checked the readme I saw this:

Placement: Static vs instance -- static postponed to follow-on proposal

So I assumed that static fields had been removed from this proposal. Next time I'll double-check the spec first. Unless I misunderstood that line in the readme, I guess it might just be out of date.

[ljharb]

Yes, that predates stage 3.

[Igmat]

@ljharb, @littledan but what about questions raised in the beginning of the thread?

[Igmat]

@ljharb, @littledan why do you ignore this thread? Should I take such behavior as a signal that you don't care about such kinds of feedback?

[ljharb]

@Igmat I think the criticism of your surveying techniques is valid. I also think that while community feedback is important, making decisions via poll is a very poor way to do language design.

Although I personally prefer [[Set]] over [[Define]], and argued for it strenuously over the previous years, i think the current proposal (using [[Define]]) is sufficient, and I think this feature is too important to delay even more over the difference between Set and Define. All other criticisms of the current proposal I've heard either fail to account for various requirements; or are objections merely over surface syntax that don't offer an equivalent better solution (or deal with Proxy issues that predate this proposal, and should be solved, but independently).

There are no questions in the beginning of the thread to answer; the only question is the one that heads your "survey" results.

Can you share any questions (new ones are fine, since there are none otherwise in this thread) for which you'd like answers?

[Igmat]

This survey represents community much better than anything provided by committee till this moment - all we have from you is only "we've talked to some peoples at conferences and they agreed with our approach".

You also mentioned, that community wants privates ASAP based on your talks with somebody (with whom?) - but as we can see community would rather prefer getting them later, than getting them broken.

I can bet that, while you were presenting current proposal to somebody who isn't aware of it fully, you were avoiding all of its controversial parts (e.g. Define semantic, brand-checking, Proxy issues and others) and you still refer to such feedback, saying "after explaining motivations. majority accepts this proposal" even though responders weren't aware of ANY trade-offs.

---

Ok, I can talk about wrong assumptions behind this proposal further and further. But my question is:

Would you make at least some steps to reach consensus with community or you're fine with your internal consensus in the room?

[slikts]

at least some steps

This continues to be rather uncharitable towards the members who have spent time addressing the issues. It's not that you haven't received answers, but just that you don't like them. The simple truth is that the process isn't and shouldn't be dictated by polling.

[Igmat]

This continues to be rather uncharitable towards the members who have spent time addressing the issues.

No important issues were truly addressed. Some of them (like Proxy problem with brand-checking) were left as is with comments like "we know that this is a problem, we don't have any workarounds for it with current solution, but we don't care - somebody in future will somehow solve it", and others left as is with comments like "we prefer X instead of Y, because... well, because we like X".

It's not a problem solving, but rather just ignor of them.

Also, I understand that some of those issues could appear because of different priorities. But committee don't share this priority list with community, despite the fact that we asked about it dozens of times.

It's not that you haven't received answers, but just that you don't like them.

I didn't get answers why some alternatives doesn't work, because after addressing several issues from committee according to one or another alternative they just stop talking about it, leaving them unassessed.

The simple truth is that the process isn't and shouldn't be dictated by polling.

I don't propose to dictate process by polling, I propose to have better process.

In this repo, we provided a lot of technical arguments against this proposal - and get answer you don't represent wider community, so these issues important only for you (3-5 persons) and not important for us (committee, 20+ persons (sorry if I'm mistaken with number)), in this case we choose to continue with our approach. In this thread I provided feedback from community - and you tell me that I'm trying to make process dictated by polling? It's wrong - I'm just trying to show that in addition to all our technical issues, we have some kind of community support that share our concerns regarding existing proposal.

[ljharb]

Nobody said they didn't care; but the Proxy thing can not be solved as part of this proposal, because it affects the existing language too. It only makes sense to address it independently.

The committee consists of dozens of people - are each of us under an obligation to explicitly and painstakingly document the things we care about, and publish them?

If there's an alternative that won't work for which you don't feel an answer has been provided, please do locate the issue for that alternative (please, not in this thread) and clarify what you don't understand?

[slikts]

No important issues were truly addressed.

This is just case in point for being uncharitable, as the one specific example you mention actually was addressed.

[mbrowne]

@Igmat @slikts Must you both describe your opinion in such an extreme way that implies those who disagree with you are completely unreasonable and unfair? I am glad that I am not the only one here defending the committee nor the only one criticizing where their efforts at transparency have fallen short, but the acrimony just makes things worse.

Although I don't want to completely side with the committee, I do feel compelled to say: there are those who have been flooding threads with an overwhelming volume of comments (I'm not referring to you, @Igmat) and it's really unreasonable to expect a detailed response to every single point raised by every single person.

[shannon]

@ljharb A private symbol approach was dismissed because it had an issue with Membranes and Proxies. As far as I understand based on your (and others') comments this issue is not new and already exists for weakmap based private. If this is a problem that should be addressed independently for the private fields proposal how can it simultaneously be an objection for private symbols?

I say this because it is becoming increasingly difficult to understand what TC39 considers important.

[ljharb]

@shannon i believe it’s the opposite problem - private symbols give too much access; the existing proxy issue is that too little access is available. It’s better imo to err on the side of proxies being too transparent in the absence of membranes rather than erring on the side of allowing encapsulation to be broken in the case where membrane-based approaches are necessary. That said, i still hope we can come up with a middle ground solution - and if we do, it would likely cover internal slots of builtins as well as private fields.