I have a class `Processor` that processes some data and I have a function `process()` that instantia...

# getting-started

[y]

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.

[CLOVIS]

Looks good to me.

[CLOVIS]

If the class is not part of the API at all, why not just

fun process(…): Int { … }

private class Processor { … }

Sounds to me like the class shouldn't exist at all, it should probably just be private top level functions

[psh]

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
    }
}

[y]

it’s a class because it has shared state

[y]

per-instance

[CLOVIS]

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

[y]

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

[Joffrey]

If Processor has state, the object option is not viable indeed

[y]

an example of this would be a BufferedReader that is initialized with a file path, and the result is a String of the file

[Joffrey]

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

[y]

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

[CLOVIS]

Also, you could just make it regular class.

class Processor {
  …

  fun process(): Int
}

[y]

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

[CLOVIS]

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

[y]

exactly. I’m trying to emulate namespacing here.

[y]

apologies if this is an XY problem

[CLOVIS]

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

[Joffrey]

@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

[CLOVIS]

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.

[y]

@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.

[y]

I’m starting to think the top-level function approach is the most idiomatic.

[CLOVIS]

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

[Joffrey]

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

[Joffrey]

The difference is in the call site

[Joffrey]

Some people have strong opinions against top-level functions

[CLOVIS]

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

[CLOVIS]

If you keep your current version, you are stuck with that class name and API (in your case: everything must always be private)

[y]

good point! the name itself is now an implementation detail

[Joffrey]

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

[CLOVIS]

@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.

[Joffrey]

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

[Joffrey]

Haha yes I was writing exactly that actually

[CLOVIS]

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

[y]

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]

that seems like a better api.

[CLOVIS]

@y what @Joffrey meant:

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

private class YourInternalState(…)

[CLOVIS]

Personally I'd put the private class in the object, but I don't think there's any standard decision on this

[Joffrey]

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

[y]

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

[y]

definitely prefer this approach. I’m glad I started this discussion.

[Joffrey]

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

[CLOVIS]

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

[y]

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

[y]

thanks a lot both of you 👍