Community feedback - Githubissues

Igmat commented 6 years ago

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.

Igmat commented 5 years ago

@ljharb I've already shown here that membrane pattern could be effectively implemented with private symbols approach without breaking encapsulation. And I even volunteered to create repo with such implementation - but nobody responded.

Igmat commented 5 years ago

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.

@ljharb it's impossible to solve proxy transparency problem, unless you agree that brand-checking isn't required for encapsulation. So any future solution will dismiss brand-check from requirements in order to solve this problem. But if you can imagine that we'll dismiss this requirement later, why do we have to stick with it now?

Igmat commented 5 years ago

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?

No, but if you want to have community support you must not ignore frequent and explicit asks from them. You may not need list of priorities for a lot of other proposals, because they aren't such controversial as this one, but for this particular case it's required to seriously justify your decision, which wasn't done (existing FAQ overs only ~30% of issues) unless committee doesn't care about community.

I realize, that I may sound very offending and aggressive. Sorry about that, I don't attack anybody personally - and I appreciate all your efforts (whether you'r committee member or not). But I'm tired - I spent a lot of time trying to figure out what happens here, how it works and justifying existing proposal for myself and I failed. I don't see any valuable reason to accept this proposal as is without even giving a chance for alternatives and arguments from proponents of this proposal are to week comparing to arguments in favor of private symbols for example...

hax commented 5 years ago

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.

This continues to be rather uncharitable towards the ~~members~~ objectors who have spent time addressing the issues (remember it's the job of TC39 members to solve the issues, not us, we discuss here in our free time or even work time with no pay). It's not that you haven't received ~~answers~~ feedbacks from the community, but just that you don't like them. The simple truth is that the process ~~isn't and shouldn't be dictated by polling~~ is just broken.

hax commented 5 years ago

@ljharb

private symbols give too much access

Actually V8 implement private field use privatesymbol-like mechanism --- the brand-check error is just like: Invalid private field 'Symbol()'

If current Symbol.private proposal give too much, we can just make it behavior just like weakmap --- this is just what V8 did.

slikts commented 5 years ago

… don't see any valuable reason …

Constructive discussion requires a basic level of charitability, and this is not it.

Igmat commented 5 years ago

@slikts do you have something constructive to say, or you're able only to repeat yourself again and again?

All technical reasoning behind this proposal, while capable of answering some questions at first glance, always failed to answer deeper questions, like in this https://github.com/tc39/proposal-class-fields/issues/149#issuecomment-440331972 or in discussion why foot-guns of [[Set]] are worse than foot-guns of [[Define]], instead committee refers to some earlier internal discussions or hidden feedback from some big projects maintainers.

We, as community, don't get any priority list or properly justified reasons for controversial parts of this proposal.

For any particular technical parts - we have number of unanswered questions and arguments. For any organizational part e.g. feedback from some guys, we have this poll and reaction of Aurelia (@EisenbergEffect) and Vue.js (@yyx990803) maintainers.

P.S.

requires a basic level of charitability

I did put much more than just a basic level. For example, this issue (#134) I started from advantages of current proposal and was trying to leave them unchanged. I spent a huge amount of time investigating Membrane pattern, it's possible use cases and implementation details (because it seems to be a reason for some decisions), even though I DON'T need it neither for my pet-projects nor day-to-day work. I put so many efforts that I even found a solution for implementing this pattern with Symbol.private proposal (which seemed to be the reason why this alternative is non-starter).

I put so many efforts to all this activities, trying to find solutions for committee problems (even though they aren't problems for me) to get NOTHING back.

Each time some of committee members didn't have answer or had to confirm that some decisions were wrong, he just starts to ignore this question, or even close unfinished issues (like #134, #136, https://github.com/tc39/proposal-class-fields/pull/140#issuecomment-428585587, #133, #122)

slikts commented 5 years ago

Charitability doesn't refer to effort but to interpreting others charitably; your statements I've quoted about the members basically portray them as irrational (supporting decisions without valid reasons) and evasive, which is obviously not the case. Me pointing this out should be helpful since it explains why you're not getting the responses you want.

rdking commented 5 years ago

@slikts I and others may indeed hold the view that TC39 has been evasive. This is true. However, what they've been evasive about is the validation of their decisions. What constraints were they bound to? What requirements must hold true? What justification validates their particular perspective that the trade-offs they're about to force onto the community will represent an overall good instead of an unwanted new collection of foot-guns?

I doubt any of us think TC39 has actually been irrational. They are obviously an intelligent group. However, we in the community can only respond to what we are shown. When we are given "just because" reasons without any divulged rational backing as a response to a rational argument complete with examples and backing justification, despite the numerous attempts to acquire the rational backing for their perspective... Well....

Suffice it to say that at some point, we eventually have to stop assuming that there is a rational reason backing their decisions at all. I don't think we're there yet. Though, I can't guarantee that this is true for all of us.

EisenbergEffect commented 5 years ago

A couple of thoughts:

We have a diverse, global community. After leading open source for 13+ years, I've come to learn that sometimes what seems as aggressive communication can just be a language or cultural difference. So, I try not to be too quick to jump on communication styles. I try to see through that to the usually meaningful point under all that. There's very rarely nothing to be gleaned from the conversation.
Some of us have interacted with various standards bodies over a number of years and have a collection of experiences which color our expectations and interpretation of responses. It's not ideal but it's human. I've had negative experiences with WHATWG, W3C, and tc39, and so have others. So, we bring that with us when we see responses coming from standards group members.
When the Aurelia core team started engaging on this issue, we saw an almost universal dismissal of our concerns. I applaud @littledan because he was someone who not only didn't dismiss things, but worked to find compromises and took action to set up opportunities for discussion. Thank you.
When we met to discuss this, there was talk about not only this feature but what tc39 could do to increase transparency, involve more people and ensure that features were designed with a solid set of use cases from the real world. We should get some concrete action items related to this and move them forward. In my opinion, this is more important than any particular language feature.
Regardless of the above, it should be acknowledged that there is an odd relationship between the web standards bodies and the rest of the world. To throw an American-ism in here, it feels a bit like "taxation without representation". The decisions made here affect the whole world but those people don't always feel that this group has our best interests in mind, nor do motivated individuals have a good way to interact. Moving things to GitHub is a positive change, but more is required.

In America we're celebrating Thanksgiving today. In that spirit I want to thank everyone that works on these standards and who engages in these often times difficult conversations. But while being thankful, let's not settle in and believe that we've arrived at the perfect process. Let's continue to work to improve all of this so that we can build the best web for as many people as possible.

/cc @littledan What next steps can we take to improve this process, engagement, communication, etc.? Should we get together some people to start brainstorming?

littledan commented 5 years ago

@eisenbergeffect Thanks for your kind message. I would be happy to brainstorm on further improvements here. I agree we're at the beginning. I am not sure if TC39 has a good place to put these suggestions right now, so how about we draft ideas at https://github.com/littledan/js-outreach-groups/issues/4 for now?

hax commented 5 years ago

FYI: https://github.com/tc39/proposal-class-fields/issues/180

littledan commented 5 years ago

I appreciate the work @Igmat put into the article described above. I'm excited to work with you on a local meeting at https://github.com/littledan/js-outreach-groups/issues/6 . Let's follow up about next steps for improving inclusion in https://github.com/littledan/js-outreach-groups .

tc39 / proposal-class-fields

Community feedback #162

P.S.