`print` and `println` instead of `echo` on CliktCommand

After having built some CLI’s lately using the library, I’m wondering if it would be beneficial to just expose print and println methods to mimic printing to the screen directly with System.out or System.err but in scope with the console’s Context instead

Example proposed methods:

protected fun println() = echo("")
protected fun println(message: String) = echo(message)
protected fun println(message: Any?) = echo(message?.toString())

protected fun print(message: String) = echo(message, trailingNewLine = false)
protected fun print(message: Any?) = echo(message?.toString(), trailingNewLine = false)

We could also consider just exposing a out and err PrintStream on the CliktCommand type

class CliktCommand(...) {
    protected val out: PrintStream by lazyPrintStream { echo(it, trailingNewLine = false) }
    protected val err: PrintStream by lazyPrintStream { echo(it, trailingNewLine = false, err = true) }

    ...

    private inline fun lazyPrintStream(output: (String) -> Unit): Lazy<PrintStream> = lazy(LazyThreadSafetyMode.NONE) {
        PrintStream(object : OutputStream() {
            override fun write(b: Int) {
                output(b.toByte().toChar().toString())
            }
        })
    }
}

at which point we could just alias the recommended methods above to go to out by default

protected fun println() = out.println()
protected fun println(message: String) = out.println(message)
protected fun println(message: Any?) = out.println(message?.toString())

protected fun print(message: String) = out.print(message)
protected fun print(message: Any?) = out.print(message?.toString())

[ajalt]

I would normally avoid overriding built in functions, since that leads to unexpected behavior. But in this case, given that echo’s behavior is identical to println’s, but it fixes line ending bugs, I think that I agree with you that this is worth implementing.

I can work on it this weekend.

[jcornaz]

I don’t think it is a good idea. Here is why:

First echo is easy to discover. Either by auto-completion or in the doc. For any library or tool, the best way to discover feature will always be to read the documentation. And in this case, we are talking about a feature which appears in the very first paragraph of the “get started” section and in each example everywhere in the doc. So it is hard to find only if we don’t read the “Hello world” of the technology we are about to use.

Then echo definitely doesn’t do the same as println. It does more.

And, println is the most known function in Kotlin. It is the first function you learn (again reading the “Hello world”), and the one you see the most often when reading articles, examples, and documentation. Every developer knows it and has a strong assumption about how it will behave. No one will think about reading the documentation of println. So providing a different println implementation will just be astonishing and unexpected.