I have a class

Processor

that processes some data and I have a function

process()

that instantiates the class and returns the result. I don’t want to have intermediate state, so I want to disallow creation of this class outside of the file it is declared in. however, I do want to call the function as

Processor.process()

. currently I have

class Processor private constructor(...) {
  //...
  private fun finalResults(): Int

  companion object {
    fun process(...): Int {
      return Processor(...).finalResults()
    }
  }
}

is there another way to do this? EDIT: basically, I'm asking for a way to emulate namespaces here.

Looks good to me.

If you are trying to group a bunch of processor methods, I would also suggest just making them top level methods. Another alternative might be to use a Kotlin singleton if you really feel you need to wrap them in an object

object Processor {
    fun processOne (): Int {
        return 123
    }
    
    fun processTwo (): Int {
        return 456
    }
}

it’s a class because it has shared state

Shared with whom? From what you've shown us the instance is local to the

process

function call.

Processor

has properties, does some (recursive) calculations, and ends up with a solution

If

Processor

has state, the

object

option is not viable indeed

an example of this would be a

BufferedReader

that is initialized with a file path, and the result is a String of the file

But the top-level function + private class is a good alternative if you don't like your current approach. That said, I find the

Processor.process()

call site nice with the current approach

yeah. I would have preferred the top-level function, but then I lose the namespacing, right?

Also, you could just make it regular class.

class Processor {
  …

  fun process(): Int
}

it’s just “process()“, and would need a more descriptive name.

What do you mean by namespacing? There is no namespacing in Kotlin.

exactly. I’m trying to emulate namespacing here.

But you asked what's idiomatic in Kotlin, namespacing is not a thing in Kotlin

@CLOVIS The regular class may or may not be viable here. It gives more control to the user and they are then allowed to call multiple times the public functions of the class on the same instance, which may break depending on what the state is

I'm not sure why you want the

process

top-level function, but it seems to me like you could just make a regular class that accepts

process

' arguments as constructor parameters.

@Joffrey explained it very well. I don’t want to allow reuse of the class instance (which may lead to illegal state) and also I don’t want to expose implementation details of the

Processor

class.

If it's single-use, it should only be internal to a top-level function, indeed

I would go with either a top level function with a private class to hold temporary state, or your current approach. Both are pretty good answers to your problem

I prefer the top-level function + private class because the class is not part of the API at all, so you can just remove it in the future

good point! the name itself is now an implementation detail

If the class has no public methods except the companion object, then it serves as a namespace, which might be desirable in big projects to avoid bloating the auto completion of the top level scope

@Joffrey no, the companion object serves as namespace. The class is useless in the API and stops you from changing it in the future. If you just want "a top-level function that isn't by default in code completion", you want a regular object.

Actually there is a third option: private class for the internal state, and then an

object

next to it, with its own name to hold the public functions you want to support

Actually if you are going with an object for the API, I would nest the private class in the object, but that's just personal preference since it's not part of the API anyway

so you can “namespace” with the public class’s companion object, and the Processor itself is a private-in-file class with a regular constructor.

@y what @Joffrey meant:

object Processor {
    fun process(): Int { … }
}

private class YourInternalState(…)

Yeah it's an option too, but I find that it usually doesn't bring much apart from an extra indent level

oh, right. so there’s not even a need for a companion.

Also it gives you the opportunity to give 2 different names. Because the namespace for the stateless top-level operations might not be a suitable name for the state holder

The good thing with this is that your internal class is 100% an implementation detail, even its existence is invisible. You also don't need to put

private

on everything, since the entire class is private

exactly. maybe in the future you want to break the private Processor class into several classes or whatever.