What is the goal of glas? about glas

[trusktr]

At the moment the first goals were to port Three.js to AS, and get it to run the demo that is detailed here:

https://docs.google.com/document/d/1CojZ_Rry3a1rQnXf8KJcSiOGodTP905CVRsU-uiWQjo/edit?usp=sharing

As a first pass, we're just copying both source and test files, and not modifying logic or making performance improvements.

This i our first time using AS, so it is a learning experience.

We would love to have performance improvements, but it will be nice to do this after the initial porting, so we can weigh the difference (not only in performance, but in type safety and maintainability).

For instance, Matrix4 would be much better off as a single heap allocation, so that copying can just be a single memory.copy() function call

We hadn't thought about any of that. We're literally just porting the code as verbatim as we can, but inevitably a few things had to be changed to make it compile in AS (f.e. convert object literals to class instances).

there are runtime checks for each set and get to validate the indexes don't go out of bounds

This seems like a good feature. I value performance, but at the same time I'd like for people to be able to easily understand the code and not make mistakes.

Many of the changes that you describe probably won't impact end-users, but they might make the code more difficult understand (further away from) JavaScript. I'd like for people to open any file, and propose changes using basic JavaScript knowledge (with only few tweaks needed like classes instead of object literals).

---

If we, for example, store matrix values as properties, how would code that needs to iterate on the values look like? Will it still be a regular for loop? Can someone make a mistake and go out of bounds?

How does it affect intellisense?

[trusktr]

Closing, but we can keep discussing here.

[jtenner]

Make it work first with a fully functional test suite, then refactor to make faster