14:23 | <Chris de Almeida> | What is the TC39 space id on Matrix? |
21:58 | <Yehor Yatskevych> | Hey there! 👋 Here is my proposal: https://github.com/yehoryatskevych/proposal-function-static-variables Please correct me if I'm wrong somewhere and I'm open for the discussion.
|
22:08 | <bakkot> | Yehor Yatskevych the most important part of any proposal is to explain what problem you're solving, compared to what you'd currently do. |
22:08 | <ljharb> | What's the problem this is solving? How would this work better than:
? |
22:08 | <bakkot> | Right now the thing you'd do is use a closure, and hoist the static variables out of the closure. How is your suggestion better than that? |
22:13 | <bakkot> | (also the main place suggestions go is the discourse; in this case this exact thing was proposed a few years ago; you may find the discussion helpful though it's pretty brief https://es.discourse.group/t/c-style-static-variables/511 ) |
22:13 | <Yehor Yatskevych> | Right now the thing you'd do is use a closure, and hoist the |
22:15 | <Yehor Yatskevych> | (also the main place suggestions go is the discourse; in this case this exact thing was proposed a few years ago; you may find the discussion helpful though it's pretty brief https://es.discourse.group/t/c-style-static-variables/511 ) |
22:18 | <Yehor Yatskevych> |
|
22:19 | <bakkot> | If it's just about encapsulation, you can do that pretty easily:
|
22:19 | <bakkot> | That would get even simpler with https://github.com/tc39/proposal-do-expressions/, if that ends up happening |
22:24 | <Yehor Yatskevych> | of course, that's how you can do it right now, but that's dirty code and it is already problematic to use this in methods. At the moment I'm looking for solutions and I'm trying to create a concept in which JS can be used as scripting engine for the gamedev and static variables is extremely useful for "update" and other functions which should be called every frame. This is also applicable for other high performance programs and recursion to avoid unnecessary allocations. |
22:24 | <bakkot> | I don't think it's especially dirty code? And it works fine for methods, not sure what you mean there. |
22:37 | <Yehor Yatskevych> | Closure
Versus static proposal.
Better readability, function declaration support, less code |
22:41 | <bakkot> | Yeah, I don't think that difference is significant enough to warrant new syntax. In practice, in almost all code, you'd just put the "static" variable immediately before the function, which has the advantage of having completely unambiguous semantics (for example: with static , what happens if you have multiple such declarations and one of them throws the first time you call the function?). In the rare cases where putting your variables before the function doesn't work, the IIFE pattern is not really that bad. |
22:42 | <bakkot> | That is to say, in practice, what you'd write is usually
|
22:42 | <ptomato> | maybe I'm not understanding the API of Vec3 there, but it looks like the variable doesn't need to be static at all in this example? isn't it always reset with .set(0, 0, 0) before it is accessed? |
22:44 | <Yehor Yatskevych> | just an example, but at least it not allocate object every frame which save time, function can be called thousand times per second and for example logic can be moved to separate function then allocation complexity will be playersNum * serverFps |
22:45 | <Yehor Yatskevych> | in case server updates 10000 times per second and we have for example 100 players it will be 100000 calls per second and the same allocations number, some the number of variables needed may also be significantly larger, it's just an example with one variable |
22:49 | <Yehor Yatskevych> | game scripts usually contain a huge number of functions and each of these functions may have its own "velocity" variable, moving it to a global context is not a solution, in case you need to somehow read the previous state you should create the same variable for each function in the global context with different names. It's easiest for me to describe it as for games, but it is almost the same for other high-loading programs and calculations. Currently, math is one of the weakest points of js |
22:52 | <bakkot> | Hoisting variables to the outer scope is in fact a solution. I agree that there are cases where that means you will need to spend slightly more effort naming things, or otherwise have some awkwardness, but I don't think this is bad enough to warrant new syntax. |
22:58 | <ptomato> | in practice how the process works is that you identify the problem first, before proposing a solution - this proposed solution moves a feature from C into JS which brings its own problems along. for example, the cognitive load for learning it due to most JS developers not being familiar with C; even in C, the feature is named confusingly, because static means two different things, 3 in C++. so during the early stages of such a proposal, there'd be a search through the solution space for a more "JavaScript-y" solution |
22:59 | <ptomato> | (& I think bakkot's point is that such a "JavaScript-y" solution already exists) |
23:00 | <ptomato> | how about, by the way:
|
23:02 | <Yehor Yatskevych> | Hoisting variables to the outer scope is in fact a solution. I agree that there are cases where that means you will need to spend slightly more effort naming things, or otherwise have some awkwardness, but I don't think this is bad enough to warrant new syntax. |
23:03 | <bakkot> | I don't think I would say without qualification that programmers love new syntax updates. |
23:04 | <bakkot> | If we added all the syntax people have proposed which would solve a problem they had, without considering the cost of new syntax, the language would be completely unusable. So we have to think carefully about how bad the problem is, and how costly the solution would be. |
23:05 | <bakkot> | In this case I think the problem is not all that bad, and the proposed solution is very costly (mostly because of the potential for confusion). |
23:06 | <Yehor Yatskevych> | hm, there is a mistake, but I get the idea! Looks like the interesting solution, however only in case you have "free" context. |
23:07 | <ptomato> | no doubt there is a mistake but now I'm curious what it is 😅 |
23:09 | <Yehor Yatskevych> | sure, you are right, let me make more investigation and try to describe the problem better and also advantages of this propose. I think functions with their own states can bring many new possibilities, not only for optimizations proposals. |
23:17 | <Yehor Yatskevych> | I mean binding context to arrow function and operation priority |
23:45 | <Yehor Yatskevych> | Also performance test:
And how it looks like with static syntax to avoid unwanted allocations:
|