Multiplatform

[elect86]

@ArcheCraft

So, about matrices, I was wondering if switching to something like

abstract class Mat2T<V, N> where N : Number, V : Vec2T<out Number>

This way we might have the component accesses down and having to implement, in the extending classes, only the abstract operator fun get(index: Int): V where the implementing matrix class can call the appropriate vector constructor..

[ArcheCraft]

Well it shouldn't be <out Number> because Boolean and the unsigned types don't extend Number. That's also something I missed, the set(index, vector) shouldn't use VecXT<out Number>... But generally that would be possible, except the overhead of creating a Vector and then just reading a value is not necessary as we are anyway just generating the code

[elect86]

Yeah right, the point is if we do want to have/makes sense matrices with boolean and unsigned

[ArcheCraft]

I created a new branch with only signed matrices, if it is ok we could also merge that or develop on that branch for now, depending of we maybe would like to come back later...

[ArcheCraft]

Also I implemented matrix multiplication on that branch

[ArcheCraft]

I guess it would be more difficult than that if there were non-signed-number matrices

[ArcheCraft]

Yeah, Boolean probably doesn't make sense. I think there are Szenarios in which unsigned matrices would be useful, but I don't know if that has that much use cases that it's worth it. Especially when we could replace all the subclasses with typealiases if we would have only matrices where T extends Number

[elect86]

ok, since you've already done it, let's keep it like this unless we come across some scenario where we need something different

[elect86]

Also, what about opening up vectors and matrices? One test on the original glm is about extending vec4
I'm all for it, but I'd like to hear if you see any drawbacks

[ArcheCraft]

I don't see any reason to not do it

[elect86]

Also super interesting regarding unsigned extending Number..

[ArcheCraft]

I would guess that still takes some time as target version is 1.7.0 and 1.6.0 basically just came out

[ArcheCraft]

Also it only works with interfaces and Number is an abstract class because it is an abstract class on the JVM (Java has it like that) and the expect/actual system doesn't allow changing between classes and interfaces

[elect86]

ah yeah, you are right, it's just for interfaces.. :/

[ArcheCraft]

Also we should think about if we want to add KDoc to the generated Functions and Classes
I guess that would be helpful to users of the library...

[elect86]

Yep, I'm all for it, but I have many more other priorities at the moment (if you want go for it, don't hesitate)
Also we could take inspiration from the native docs

[ArcheCraft]

And another thing to think about is if we want to keep the system with a glm object and providing the functionality via interfaces as we already started with a different approach (being that we implement the stuff directly on the target class)

[elect86]

This should be driven by practical reasons. Let me say that I opted for the interface design to have modular code and give the option to the end user to build its own glm handler (similar like on c/c++ where you have specific functions based on the headers you import). Another reason actually was to have just one unique place where the logic is executed, for testing convenience, but anyway..

[elect86]

I never saw unsigned matrices so far, so unless we are proven otherwise I'd say let's merge that and continue

Also, I'm porting directly from the native library

Edit: shall we keep the constructor for building matrices by diagonal? That is, ie Mat3

	constructor(x: Number, y: Number) : this(x, y, 1)
	constructor(x: Number, y: Number, z: Number) : this(
		x, 0, 0,
		0, y, 0,
		0, 0, z)

Edit2: maybe it's better to avoid any operation on generic and write down every specific implementation, such as:
fun <N : Number> times(res: Mat2T<N, out Vec2T<N>>, a: Mat2T<N, out Vec2T<N>>, b: Mat2T<N, out Vec2T<N>>)
I'm afraid that in hot loops this may penalizes us substantially..
And we are generating code already, so..

[elect86]

Do you think this would be useful

I honestly don't know. If you feel it, you can go ahead. Otherwise we can postpone this later on when/if we get some more feedback about it and focus on other stuff

I opened an issue though for the swizzle compile time

[ArcheCraft]

Actually on my PC it did run the tests, it just took like 15 Minutes...

[elect86]

Uh, ok, but still unfeasible for development

Btw, I noticed glm does indeed have unsigned matrices (beyond float, double and int), shall we do the same?
Edit: we could leave out the unsigned given it doesnt extend Number for the moment, since Mat*T requires that constraint

[elect86]

Also, what about we move width and height as top level properties and avoid passing them every-time again and again?

[ArcheCraft]

That makes understanding the code much harder as the code flow is not (that) clear
And i would say easy readable code is more important than typing a little bit less