10

So if extension methods and extension properties are really static methods and properties. And static methods and properties and methods are not thread safe and therefore should be avoided then extension methods and extension properties are bad.

We are just tricked to do those because the codes we write will appear as pretty or clean but performance-wise it is not.

Is this true?

LEMUEL ADANE
  • 8,336
  • 16
  • 58
  • 72
  • 12
    No, the statement "static methods are not thread safe" is not true (and neither it's false). – Ilya Nov 14 '16 at 21:36
  • If it was about thread safety then the entire object orientation would be bad. Unless there was no mutable state, and objects could only be constructed by their constructors, and methods returned new instances of the immutable objects. – Luiz Felipe Mar 05 '21 at 18:54

3 Answers3

13

It depends on how you wrote extension function/property. If they doesn't edit or access shared state i.e. if property and function is clear function: it absolutely not bad practice.

Example 1:

fun String.countSpaces(): Int {
    return this.count { c -> c == ' ' }
}

This functions works perfectly in multi-threaded environment, since String is immutable.

Example 2:

data class MutablePerson(val name: String, var speech: String)

fun MutablePerson.count(nextNumber: Int) {
    this.speech = "${this.speech} ${nextNumber}"
}

This function mutates speech property of MutablePerson object and assign operation is not atomic. If count will be called on one object from different threads - inconsistent state possible.

Example:

fun main(args: Array<String>) {
    val person = MutablePerson("Ruslan", "I'm starting count from 0 to 10:")

    (1..10).forEach { it ->
        Thread({
            person.count(it)
            println(person.speech)
        }).start()
    }

    Thread.sleep(1000)

    println(person.speech)
}

Possible output:

I'm starting count from 0 to 10: 1
I'm starting count from 0 to 10: 1 3
I'm starting count from 0 to 10: 1 3 4
I'm starting count from 0 to 10: 1 3 4 2
I'm starting count from 0 to 10: 1 3 4 2 5
I'm starting count from 0 to 10: 1 3 4 2 5 8
I'm starting count from 0 to 10: 1 3 4 2 5 6
I'm starting count from 0 to 10: 1 3 4 2 5 6 7
I'm starting count from 0 to 10: 1 3 4 2 5 6 7 9
I'm starting count from 0 to 10: 1 3 4 2 5 6 7 9 10
I'm starting count from 0 to 10: 1 3 4 2 5 6 7 9 10

So extension functions and extensions properties not bad practice, they are just like properties and method in classes: depending on how you wrote they thread safe or not.

Ruslan
  • 14,229
  • 8
  • 49
  • 67
9

Static methods have their own stack just as instance methods. So temporary vars inside a static methods are on the stack just as for instance methods. parameters that are handed in to a static method may be subject to threading problems when accessing shared state, but this is exactly the same situation with instance methods.

Think of the enormous amount of Util classes in Java with static methods as a workaround that Java does not have extension functions. Nothing has gone wrong there with regard to multi-threading.

Also in C# extension methods are behind the scene static methods and it doesn't do any harm, see How extension methods are implemented internally

Community
  • 1
  • 1
OlliP
  • 1,545
  • 11
  • 22
0

As you said, extension functions are solved statically. So if you start using extension functions as a way make Utility classes, then it's a bad practice.

In Java, Utils class are usually a bad practice, not only because of the thread safety but also because they can be a code smell for bad design and because they are hard to test.

The main problem with static methods is that they can't be mocked (with Mockito at least), so you will hand up being unable to test your code.

But, if you use extension functions for small, isolated tasks that have no need to be tested then it's not a bad practice at all (like helper for Toasts, Logs...)

rontho
  • 439
  • 4
  • 11