Operators overloading for components and entities

[pylvain]

We already have one operator overloaded, it's += for adding a Component to an Entity.
Let me introduce another :

operator fun <T : Component> Entity.plus(comp: T) = apply {
    add(comp)
}

No we can write :

val entity = Entity() + Component1() + Component2() + Component3()

Maybe we would also want to write :

entity += Component1() + Component2() + Component3()

However, since += operator have the lowest precedence, we have to add Components to a list-like structure before assigning them to the entity, and that can cause performance issues. We need to write these three functions for it to works :

operator fun <T : Component> Entity.plusAssign(l: List<T>)
operator fun <T : Component> MutableList<T>.plus(other: T): MutableList<T>
operator fun <T : Component> T.plus(other: T): MutableList<T>

I was curious about performances vs adding components one by one. I made three implementations of theses three functions.
One with MutableList :

interface Component1 : Component
class RandomComponent1(val i: Int = 0 ) : Component1

operator fun <T : Component1> Entity.plusAssign(l: List<T>) {
    for(it in l ) {
        add(it)
    }
}

operator fun <T : Component1> MutableList<T>.plus(other: T) = apply { add(other) }
operator fun <T : Component1> T.plus(other: T) = mutableListOf(this, other)

Another with a self-made implementation of LinkedList :

interface Component2 : Component
class RandomComponent2(val i: Int = 0) : Component2

class LinkedList<T>(val value: T, val next: LinkedList<T>? = null) {
    fun append(v: T) = LinkedList(v, this)
}

tailrec operator fun <T : Component2> Entity.plusAssign(l: LinkedList<T>?) {
    if (l != null) {
        add(l.value)
        plusAssign(l.next)
    }
}

operator fun <T : Component2> LinkedList<T>.plus(other: T) = append(other)
operator fun <T : Component2> T.plus(other: T) = LinkedList(this).append(other)

And another with ArrayList, with an initial capacity

interface Component3 : Component

class RandomComponent3(val i: Int = 0 ) : Component3

operator fun <T : Component3> Entity.plusAssign(l: ArrayList<T>) {
    for(it in l ) {
        this.add(it)
    }
}

operator fun <T : Component3> ArrayList<T>.plus(other: T) = apply { add(other) }
operator fun <T : Component3> T.plus(other: T) = ArrayList<T>(10).apply { add(this@plus) ; add(other) }

Then i ran some benchmarks :

Benchmark with 10000000 iterations : 

Benchmark 0: No lists, += 1 by 1
2 Components : 1114
5 Components : 1692
10 Components : 2747
Benchmark 1: List
2 Components : 1303
5 Components : 2196
10 Components : 3819
Benchmark 2: LinkedList
2 Components : 1238
5 Components : 1977
10 Components : 3357
Benchmark 3: ArrayList with initial capacity of 10
2 Components : 1338
5 Components : 2044
10 Components : 3463

I really like the LinkedList implementation, it's memory efficient since we aren't dealing with a lot of components, and it's not a lot slower than the +=. The problem is that the order is reversed : the first component before the += will be added last

What do you guys think of that ? Is it worth adding or not ?

[czyzby]

The + operator should not mutate the object, but rather return a new one with updated state. I believe the implementation from the standard library for things like the collections make a copy of the original object. I don't think it's a good fit for entities, since we should avoid copying the entities and its components. += is perfectly OK, since mutation is fine for this operator.

I also wouldn't touch + operator for components, since A) the library users might want to provide their own operators for some components where it makes sense (e.g. Transform + Vector2), B) the use is very niche and is unlikely to improve the readability by much in case of components with multiple constructor parameters.

I know that some KTX modules might be still guilty of this with the overloaded operators, but I'd prefer if we didn't add any utilities that violate the Kotlin guidelines.

[pylvain]

The + operator should not mutate the object, but rather return a new one with updated state. I believe the implementation from the standard library for things like the collections make a copy of the original object. I don't think it's a good fit for entities, since we should avoid copying the entities and its components. += is perfectly OK, since mutation is fine for this operator.

I forgot about that, that's totally true

I also wouldn't touch + operator for components, since A) the library users might want to provide their own operators for some components where it makes sense (e.g. Transform + Vector2), B) the use is very niche and is unlikely to improve the readability by much in case of components with multiple constructor parameters.

I can understand that.

In a project of mine, I was in need of a tool to add multiple components at once, just for prototyping, so I thought of that and operator overloading is tempting ... But I know now not the way to go, a vararg function can do the same thing. Thanks for the return.

[czyzby]

The + operator for components is not necessarily bad, it can be a quite nice DSL along with the entity += syntax. If you're considering using this in your own projects, I'd say the syntax is quite nice. It's just that without any other support in the Ashley library (like a built-in specialized component list), I don't think we should add it to the core utilities.