Thanks for using github & the MIT License.
You betcha, it's a de-facto standard in the JS dev community, which is my side of the pond.
I'll be looking at this, as I am doing a very similar project, also MIT licensed. My main current focus is on:
- Turn the insanity of JavaScript into a modern programming language & environment.
- Basically restrict the developer from shooting himself or herself in the foot & wasting hours chasing bugs.
I agree on the big-picture. Currently the ES5 MV codebase is kind of a cluster, and I think moving to a more robustly-documented, modern (and IMO, typed via TypeScript) one would help fix a lot of those issues.
Understandable & real class system like all modern programming languages have (instead of the prototype craziness that 99%+ of JavaScript developers do not really understand -- i.e.: causes confused thinking)
So ES6/TypeScript has Classes, which are sugar for the prototype system. I'm under the impression that most peoples' issues with the prototype system are more an education problem than intrinsic to prototype-based inheritance.
Factories, instead of new
I feel less positively about this. I think with the ES6 class system, classes make a good deal more sense than factories and more "traditional," Java-esque OOP. SOLID is way better (and idiomatic) for Java or C# than JS.
Composition instead of inheritance (long term focus is interface & traits). Inheritance will be allowed, but will probably be optimized into composition (user option).
I'm slightly more on board with this, but I still think JS is much less well-suited to ECS than other languages, even when you introduce typing. Sure, TS's interfaces will get you part of the way, but even TS has no support for mixins or traits, which'd be a big part of any composition system.
All class members must be declared properly before use. You may not create random new class members without declaring them first -- it will throw errors at you if you do. In case the above was not clear, the use of '.prototype' is also outlawed. It will throw errors at you if you try to use it. Throw errors on all illegal attribute accesses. I.E.: If you say window.oops, it will throw an error instead of returning undefined.
I don't know that this'd be enforceable in JS. You could proxy everthing, but the perf hit from that would be extraordinary.
All functions, members, methods, and especially closures, must have a .$name & .$summary member, to make everything super easy to introspect & understand from Developer Console (Only in debug mode, in release mode, these are not created or used)
Hmm. I think a proper typing system would obviate the need for many of these. I don't think the console is really the best place to be doing source inspection, apart from trivial logs -- source maps are much more idiomatic in JS, and if you set things up properly you can use the debugger with them.
For development, lots of separate *.js files instead of a single js/plugin/*.js file (for release, would combine it back to a single js/plugins/*.js file). Individual *.js files must be small, self documenting (i.e.: see .$name & .summary) -- so can click on their link in Developer tools & quickly see their source code without tons of surrounding distracting other stuff.
Yeah. ES6's module system would make this much more doable -- it's much more oriented toward a modular architecture. Source maps can get you the source code view part.
No use of global variables, everything done via closures (i.e.: imported & documented), so easier to understand code.
Yeah, agreed, the globals are unmaintainable.
In debug mode, Proxy everything (so can throw errors on illegal attribute access; also protect 95% of members as immutable.)
You can make stuff immutable without using Proxies.
https://facebook.github.io/immutable-js/ is a great library that allows that.
Allow dynamic reloading of code (which invalidates all previous instances from that code -- partially relying on Proxies to achieve this). This allows changes to reload in 0.1 seconds instead of 10 seconds+.
Agreed, hot module replacement would be awesome. Webpack has a great API for this:
https://webpack.js.org/api/hot-module-replacement, but we'd need to start using a module bundler in order to see any benefit from that.
I think it would be great to have a group of developers support a common set of plugin's together & build out a common code base that makes it 10x easier to develop and understand plugins.
Also agreed. Currently, the code quality in the ecosystem is pretty low. Waaaaay too many evals.
Overall, I agree with a number of your points. But as someone who works professionally in the JS ecosystem, I think some of them are impractical, implementation-wise, for a JS codebase. I've forked a TypeScript conversion of CoreScript that looks really promising. I'll see if I can get it up on Github at some point, would probably be a good starting point.
One of the greatest strengths of MV, is, despite its many issues, the plugin ecosystem. I think the most important parts of a re-envisioning of Corescript would be (in no particular order) a) maintaining a compatibility layer/plugin for existing plugins, while deprecating things like global access, &c. b) getting some sort of testing suite up and running c) maintaining compatibility with the editor, to the point where an existing project could have CoreScript swapped out and function as expected and d) switching to a module-based architecture.
Those sound more important to me than moving to a more traditional OOP architecture. If you create an entirely API-incompatible CoreScript re-implementation, absolutely no one is going to use it - in my opinion. People are going to stay where the plugins and the editor are, and so maintaining compatibility with those is critical.
