Is it legal to use Primitive data types T directly for AutoComp?

[Glidias]

Trying something out "funky", to avoid using an object/class wrapper to hold primitive data, but store data entirely as a non-object-based data type in array if it only consist of 1 field, in order to save memory.

class AgeTest extends AutoComp<String> {}
class AgeTest2 extends AutoComp<Float> {}

At the cost of a bit more initialization boilerplate.

 // in some entity creation function... entity = world.create();
	_ageTest.create(entity);
	_ageTest.set(entity, "Default");
	_ageTest2.create(entity);
	_ageTest2.set(entity, 5);

And in some system processing...

var  ageTest2:Float = _ageTest2.get(entity);
_ageTest2.set(entity, ageTest2-=dt);

Would be considered ok, right? I tested it on Asteroids. Compiles fine. Runs fine.

---

BTW, I even tested with Age extends AutoComp<Int>. There was an error because you did not support Int, so I made some changes...and also hooked it up to ds CInt32Array instead (counting in ms integers instead so i -=Std.int(dt*1000)) instead. From my Asteroid test, it appears fine and works as per normal., which would be good as it'll make use of CInt32Array which JS target takes advantage of as well.

The change i made to support primitive Int/UInt.. (seemed that you missed out "Int"/"Uint" primitives?? I saw you have "Float").
Glidias@1985603

Not sure about the repucussions if I use CInt32Array to cover UInt data types though, even thoughit runs fine as far as the compiler is concerned. Of course, UInt will have different implications value/result-wise.. I'm not too sure about this..... (scratches head..)

[eliasku]

I plan to separate dense / sparse packing, so for sparse storage CArray would be enough. For dense packing you should check something memory access efficient, for example js target provide efficient typed arrays, so Float32Array for float32, and UInt32Array for uint32. You probably already checked hotmem library.