Attendees: Yulia Starsev (YSV), Daniel Ehrenberg (DE), Shu-yu Guo (SYG), John Hax (JHX), Leo Balter (LBR), Jordan Harband (JHD), Chengzhong Wu (CZW), Ukyo (???)
SYG: I am skeptical about the proposal to reflect the presence of this and how this is used in a function. My understanding of the current proposals is that it is trying to capture two notions when both are true.
Are you using the this keyword
Does the this keyword bind the receiver.
This is intended to capture the intention of the programmer. By having this reflected, then frameworks and other libraries can do some work and throw errors or do other work to help programmers.
JHX: Yes this is an accurate picture of the goal of the proposal
SYG: I have a number of concerns with this. For the first bullet, there are many many platform functions. There isn’t any source text to inspect there. Does this extend beyond user functions?
JHD: I would expect that every function, language and platform, would have to be marked
SYG: that seems infeasible for me. For number 2, the adoption path for using this requires monkey patching all platform apis. This is error prone and undesirable.
JHX: Is this concern about polyfills or the browser implementation?
SYG: suppose that this was in the language and you can use it, a user library that takes callbacks can enforce it. But for platform functions that take callbacks, they do not enforce this unless you replace native functions with a wrapper.
JHX: I think you mean how current platform apis use this feature. This feature is for frameworks, but it could also be used for future platform apis. I don’t suggest replacing any existing apis.
SYG: Moving on to the next point I had, since the purpose of this is to capture user intent -- this does not necessarily fulfill that requirement. A lot of libraries do forwarding, the answer about what the intent is depends on the function that is forwarded to.
JHX: If the author does not want to test it, they can just ignore it. The key point is to provide a mechanism for the author to create a constraint. At the moment it is impossible to do.
SYG: my point about the forwarding functions is not that forwarding functions themselves need to check this, but the goal function. How would the framework answer this? Ultimately it feels like, yes this is not possible today, but I do not think this is possible in general. I do not think we can have an exhaustive way to reflect programmer intention.
YSV: The point brought up about the platform I think is a real concern. If the only way to use this is through monkey patching platform then this will either hobble this solution, or will require enormous complexity to be added to the platform. I feel like this does not solve the problem that is raised and this is not the right approach.
JHX: I don’t expect that we change any existing platform apis. What I would want to do is add a property, an internal slot, for each platform function -- whether platform or not -- I am not sure why it cannot be provided by the platform. Right now users use type systems
JHD: I do not use a type system, and for all language and platform builtins I feel like any reflection mechanism should be truthfully and accurately reflected upon. And if that is not possible then it may be better not do this. Separately, Promise.all and friends do require a receiver. also Array.from will obey one if given yet has a fallback to the Array intrinsic if one is not provided, should that be marked as expecting a receiver or not?
SYG: I think the point about promise combinators is an important one. [... missed discussion]
LBR: Everything I am going to say matches what shu and yulia have said. Hax, I totally understand the problem that you mentioned, but I want to separate the problem from the proposed solution. I have less of an implementer view than syg and ysv, but a web dev view. I have seen cases like this where the solution proposed is too high level, and I see that here as well. This seems to be a problem that exists more in userland than in implementations. I think there are many ways to solve this, such as syntactical solutions like passing bound functions. I think the problem is that we have different programming designs. This solution shows a case where we are trying to merge two different designs from classes and event callback style. I think the problem lies in which level has the responsibility here to fix this problem, implementation or user land. This happens a lot with the Intl api -- it is low level and intended to be abstracted in user land. The other issue is the cost, as Yulia has mentioned -- this will cost too much.
SYG: what do you mean by low level
LBR: what we offer from ecmascript built-ins.
YSV: I think we should make clear what "cost" means here. It's important to differentiate what we mean by cost. It's not financial or anything like that, it's the cost of implementing such as browser performance.
JHX: how can we solve this problem fully? I don’t know if there is a way. There is a type system, but w will not do this
SYG: I don’t think this problem can solve this using runtime reflection. A type system restricts the number of accepted programs. But that is not the design philosophy of javascript.
JHX: If we think it is a problem, we need to find the best way to provide for programmers. Whether they use it or not, but if we do not provide it then nothing will happen. I would compare this to the brand check that jordan proposed. But this feature does not have any work around. Programmers have no way to do that. I think it is wrong to say that this is not useful.
JHD: So two things: forwarding functions are when I wrap a function with an outer function, how does the outer function set the this property correctly. The solution is that you would manually do that in the proposal. But that clarification actually conflicts with the argument that there is no way to do it. You could currently do that and sent such a field manually. This is why browsers are against this, because this is effectively why it doesn't make sense to do in browsers as they would also have to do this at run time.
YSV: yes this is exactly the issue. And there are cases like the problem Jordan mentioned about arrays.from (also array.of) which can take a special constructor, making the answer as to whether or not this is expected ambiguous. A separate problem exists with promise combinators, where for example, all will throw without a constructor.
JHX: what about userland functions then?
JHD: the current work around absent this proposal is that you explicitly annotate your functions. Now, that is impractical.
JHX: but frameworks would take any code:
JHD: yes, but I think it is worth pointing out that there are frameworks that have asked users to manually annotate their functions much like react.
SYG: Let me try to rephrase something in Jordan’s framing. This is really a protocol. We all kind of agree that the actual true intention of whether you expect this in a certain way, is not easy to determine from pure syntax. Some is conditional like Array.from, but it is not acceptable to have a language level property for which we cannot provide a coherent answer. It is acceptable for a framework but not for an implementation. You are asking the entire language and everything it touches to adopt this protocol, and that is not feasible.
LBR: when we talk about convention, we cannot enforce it at the language level. Conventions are meant to be interpreted differently by different groups of development, it's good to have different conventions (if you're not in the same team/group).
LBR: The problem that I see is around transferring a method and losing a reference to this. We are trying to offer a tool to empower verification rather than fixing the problem itself.
YSV: Would we be happy putting something into the language that would give the wrong answer? I think that is the real issue here. I for example am not comfortable with introducing an api that gives an answer that users cannot rely on. The purpose of this proposal is to reduce error proneness, and this has the potential to increase it.
SYG: the fact that this is configurable makes this even more worrisome.
JHX: we can make it non-configurable.
SYG: but if it is non-configurable, then you cannot deal with the edge cases.