3

While working with Kotlin, I see you can define methods in a Kotlin file that has no class or object type (i.e. a file without class Test or object Test). I also see when you put methods into a Kotlin file without the class or object keywords, you need to import the method (i.e. import com.package.testMethod) to the file you want to use it. A little more context, I was trying to make some utility methods and started tinkering with both object and kotlin file with no class/object

My question is what is the use case for having a methods that aren't in some kind of object file? And when would you want to use this over something like object?

Spartan Tex
  • 33
  • 2
  • In an app, I would lean towards putting the functions on some type, whether that is an `object`, an existing type (extension functions), or some type that you create. The Kotlin standard library makes extensive use of top-level functions, though. Think of `listOf()` and `mapOf()`, for example. Popular Kotlin extension libraries also use top-level functions: `flow()` for creating a `Flow` with the coroutines library, `startKoin()` in Koin, and so on. In the end, it is about promoting ease of use for widely-used bits of functionality. – CommonsWare Aug 02 '19 at 00:24
  • Possible duplicate of [Kotlin top-levels functions vs object function](https://stackoverflow.com/questions/54862918/kotlin-top-levels-functions-vs-object-function) – Alexey Romanov Aug 02 '19 at 05:58

1 Answers1

3

You can either put your methods in the top-level declaration or inside an object. It's all about whether you want to pollute namespaces or not. You can have a function named X in an object and you can still have a function name X in a different object file since you can refer to specific method with the help of their object name. But you won't be able to do this if you declare methods top-level, each method would need to have a unique signature name(not counting overloaded methods).

Additionally, object can have supertypes, meaning you can inherit other classes or implement interfaces. Neither introduces more technical capability over another. If you define variables in an object or as top-level, both will be initialized lazily.

In short, it depends if you want to pollute namespaces or not.

Taseer
  • 3,432
  • 3
  • 16
  • 35
  • So which implementation pollutes the namespace? – Spartan Tex Aug 02 '19 at 01:37
  • The one without `object` – Taseer Aug 02 '19 at 01:50
  • 1
    If the object has nothing in it other than functions, I don't think there's really a difference in terms of "namespace pollution". Top-level functions are namespaced by their package, while functions in objects are namespaced by the object's class name and package. Therefore, you can create equal levels of namespacing by creating a package rather than an object (e.g. `com.example.MyObject.myFunction` vs `com.example.mypackage.myFunction`). – Ben P. Aug 02 '19 at 02:43
  • Agreed, what if there is more than one file in the same package, then there could be a naming conflict, but using an `object`, there won't be a naming conflict. I think that if we want to work in the same package, then `object` could be handy otherwise declaring methods top-level is the way to go. – Taseer Aug 02 '19 at 08:24