Potentially in es2018, likely in es2019, instance variable in classes will exist. Our analogy is usually Vlt. The problem for the end user to use this is that our entities o ly have one instance with different contexts passed to them. The least complex fix to allow this feature, would be to create imp instances for each entity. Performance consideration being ram. An alternative, would be to catch the state of the object when passed back in the imp eval for default state information. Methods could be pulled out of prototype, while default Vlt information could be put into a new dictionary, for setting up instances of that entity later. This would get hairy though, because we are clearly misusing the syntax, and further development of JavaScript as a language would likely only make it worse.
We should run some tests to see what the memory implications really are for converting the imp cache over to something with proper instancing.
Potentially in es2018, likely in es2019, instance variable in classes will exist. Our analogy is usually Vlt. The problem for the end user to use this is that our entities o ly have one instance with different contexts passed to them. The least complex fix to allow this feature, would be to create imp instances for each entity. Performance consideration being ram. An alternative, would be to catch the state of the object when passed back in the imp eval for default state information. Methods could be pulled out of prototype, while default Vlt information could be put into a new dictionary, for setting up instances of that entity later. This would get hairy though, because we are clearly misusing the syntax, and further development of JavaScript as a language would likely only make it worse.
We should run some tests to see what the memory implications really are for converting the imp cache over to something with proper instancing.
http://2ality.com/2017/07/class-fields.html