or it means that any expression can be there, it just needs to evaluate to Boolean?

ah wait, I got it

x is evaluated to say 5, then parseInt("5") is evaluated and matched against x 🙂

Currently I need a way to pass this

x

to the function, ala

when(x) {
  is SomeException -> do1()
  isSomeComplexExceptionCond(x) -> do2()
}

but I guess this is impossible and I need to use arugment-less

when

instead:

when {
  x is SomeException ->
  // etc
}

I like the new Slack logo

👍🏽

Hi guys

Does anyone know about something like dotEnv but for Kotlin?

@jackmiras you cannot set environment variables for the current process. are you looking for a config lib that can read from environment variables, system properties and config files?

https://github.com/typesafehub/config is a pretty good starter if you don't want to bind/datamap your config for POJOS

Is this a known bug? Kotlin suggests me to replace

fun fail(i: Int?) = i?.let { intArrayOf(it) }

with

fun fail(i: Int?) = i?.let(::intArrayOf)

which does not compile

@Paul Woitaschek it doesn’t suggest it to me in 1.1, probably a fixed bug?

it suggest me in 1.1 RC

@User uploaded a file: and commented: I don't see any suggestion.

@User uploaded a file: and commented: Do you mean an action with Alt+Enter? It's not a suggestion, it's just an action you can perform automatically if you wish. Like other actions in the list.

@User uploaded a file:

Ah, I’m sorry, I had this inspection turned off 🙂

This is a bug, please report to kotl.in/issue

We’re using it for backend development, so not a critical requirement like with Android, but I thought I’d rather double check

@janvladimirmostert How are you finding it for backend development compared to using say vanilla Java?

Wish I could use it for backend development.. Java really annoys me. Constants nowhere

Or if there are, everything is filled to the brim with final

@bigkahuna Classes that only transfer data simply cuts down by 50 - 75%, so a 1000 lines class becomes 250 -500lines which means code reads much easier. In the case of business logic, code is much more concise and in the cases where we handle a lot of data objects, no more nested layers of if (… != null)

it’s really the best thing since sliced bread

Since starting to use Kotlin, we also ditched Spring and AspectJ and Lombok (Lombok was only used in some of the projects), Apache Commons and a gazillion other things which now comes out of the box with Kotlin. So instead of a bulky Spring project, we have a very lightweight Kotlin project.

Lightweight meaning very few dependencies

Wait, you ditched spring?

And using what instead?

@sreich We used Spring for dependency injection, Spring Data with Hibernate, Spring AMQP to get RabbitMQ access, Spring Integration for connecting stuff, Spring MVC for HTTP endpoints, Spring Web Services for SOAP, Spring ROO for DB model generation, etc We used a lot of Spring components! Now we simply don’t use dependency injection anymore, the Kotlin syntax is powerful enough to write our own interfaces that wraps singletons, so where we need that pattern, it’s simple enough to do it ourselves. Spring Data we ditched as well as aspectJ and Spring Roo which were all wrapping Hibernate objects (Spring Roo generates Hibernate / JPA objects with so much AspectJ boilerplate that it just had to go), using straight Hibernate with some Kotlin method extensions meant our only dependency is now Hibernate and since there’s no annotation scanning, startup time of the project has reduced dramatically. Further, we get a lot more control over the process since ditching Spring wanting to manage the whole EntityManager lifecycle. Our Hibernate models also went from 1000s of lines to just the bare-minimum code needed to represent the database model since all generated Spring Roo stuff disappears, getters and setters disappear, etc. Spring AMQP we replaced with straight RabbitMQ Client library and using some extension methods, we made it idiomatic Kotlin in order to get exactly what we need without any of the stuff we don’t need. Spring MVC we replaced with VertX + VertX Web, although I quite like Spring MVC, I like VertX so much better. Spring MVC has so much in it that we don’t need - Spring MVC is bloated compared to VertX, application startup is now in the millisecond range instead of taking 5 seconds to startup. Spring Web we’re still considering options, the way it can generate a WSDL is quite neat, but we’ll probably make the WSDL a static file and use some form of XML parsers combined with VertX. We have a lot of code that needs to work at the servlet level and still need to access the spring context, going vertx we get rid of the servlet and spring context which means we’ll reduce clunky inject spring context code into servlets or extracting servlet http requests into spring context. Spring Integration we easily replaced with Apache Camel, we’re looking at writing our own Kotlin DSL for Apache Camel, but so far the Java methods with some extension methods is working quite well for us. Spring Security we just rolled our own - extension methods + VertX gives you many options for request filtering. Spring Security was painful to work with, certain things we had to bend backwards so that Spring Security could work and then getting the annotations working was painful - now we just have Kotlin code, much easier to reason about the security that having to guess what Spring Security is doing. To replace Spring Config, we just rolled a simple 100 line lib that gives us exactly what we needed with regards to configs and we can actually do with it exactly as we please, even have it reload configs in realtime whereas this was difficult with Spring.

oh, spring roo is a nightmare