kotlin 세미나 필기

경고 : 이 문서는 오타수정을 포함해 정리를 하지 않은 필기로 잘못 들었거나 잘못 이해했거나 기타 등등 잘못된 내용이 얼마든지 많이 포함되어 있을 수 있습니다.

발표자 : 익명 처리함…

  • 특기 사항 : 코틀린보다는 스칼라+스파크+제플린을 더 좋아함.
  • 안드로이드에서 잘 맞음.
  • jvm에서 돌아가는 언어로서 자바와 호환됨.
  • intellij에 to Kotlin 기능이 있음.
  • 정적 타입 언어.
  • 안드로이드는 공식적으로 java 6까지만 지원함.
  • 달빅 vm은 method 갯수 제한이 있다. 약 6.5만개. 큼직한 라이브러리, jodaTime, guava 등이 각각 1만개 근처이므로 큼직한 라이브러리 몇 개만 넣어도 뭘 할 수가 없다.
  • 스칼라를 안드로이드에서 쓰려는 시도도 있었지만 스칼라 자체가 거대한 라이브러리로(메서드 약 5만개) 구성되어 있어서 안드로이드에 직접 쓰기는 몹시 부담이 된다.
  • 때문에 간결하면서 유려하고 모던한 새 언어의 필요가 있어 코틀린이 탄생함.
1
data class customer(val name: String, val email: String, val company: String)
1
val psitiveNumbers = list.filter { it > 0 }
1
2
3
object ThisIsASingleton {
  val companyName : String = “testname”
}
1
2
3
4
5
6
7
8
9
var output : String
output = null // 코틀린의 타입은 래퍼이기 때문에 String type이면서 동시에 값이 null일 수 있다. ?와 !!로 제어 가능.

fun calculateTotal(obj: Any) {
  if (obj is Invoice) {
    obj.calculateTotal()
  }
}
//is 문은 타입 검사며, 이 문 안에서는 자동으로 타입 캐스팅 된다.
  • 자바 라이브러리를 직접 사용할 수 있다.
  • JavaScript. Write code in Kotlin and target JavaScript to run on Node.js or in browser(자바 스크립트로 컴파일 할 수 있다.)
  • 컴파일 속도가 가볍고 빠르기 때문에 스칼라와 달리 안드로이드에 매우 적합하지만 그만큼 기능은 적기 때문에 서버에서는 굳이 쓸 이유가 없다.
  • 안드로이드에서 코틀린을 쓸 때의 장점은 매우 많다. 람다도 쓸 수 있고, 클래스에 익스텐션을 만들 수 있고(기본 타입에 메서드를 추가할 수 있는 것을 의미)
  • 코틀린 런타입은 1071개, 표준 라이브러리는 약 5000개로 매우 가볍다.
  • 비트윈이 모든 코드를 코틀린으로 바꾸지는 않았다. 디펜던시 인젝션을 위한 apt, 버터나이프(코틀린 전용으로 래핑한 kotterKnife도 있음.) 라이브러리(스프링에서 어노테이션으로 인젝션 해주는 것 같이.)가 자바 라이브러리인데 어노테이션은 제대로 코틀린에 적용되지 않았다. 그러나 지금은 지원함. 따라서 올해 중에 완전 변환 할 것.
  • menu : Menu?는 Menu를 Optional 타입으로 할 때.
  • 자바와 달리 코틀린은 이중 상속을 허용한다. 이 때문에 슈퍼의 것을 사용할 때 어떤 것인지 명시해주어야 할 때가 있어 toKotlin이 완전하지 않은 경우가 있다. 이외에는 별 문제 없음.
  • 코틀린 표준 라이브러리에서 array, list 등 자바에서 기본적으로 제공하는 라이브러리를 따로 가지고 있다. 자바 기본은 너무 오래되었고(..!), map, reduce 등을 쓰기 위해 표준 라이브러리에 추가함. 그런데 이게 인터페이스만 있고 구현은 빠져있다.
  • 스칼라는 방대한 컬렉션 라이브러리를 가지고 있지만 코틀린은 가볍게 하기 위해 컴파일 시 필요한 파트만 구현을 제너레이트 해서 집어넣는 방식으로 가볍게 한다.
  • 그런데 안드로이드 킷캣 이후로는 cpu를 더 쓰더라도 메모리를 적게 쓰기 위해 컬렉션 라이브러리 구현을 통합했다(? 난 잘 모름..). 이게 코틀린에서 어떻게 될 지, 잘 예측할 수 없다. 안드의 최신 컬렉션 라이브러리가 성능이 더 좋은 거 아닐까? 재밌는 주제. 그런데 자료형 구현의 성능이 그렇게 아주 큰 차이는 나지 않을 것으로 예상됨.
  • 성능은 자바보다 약 5% 정도 떨어진다. 이 정도 차이는 최적화로 따라잡기 쉽지 않은 차이긴 하지만, 생산성 증가가 워낙 높고, 파이썬 등과 비교하면 대단히 성능이 높기 때문에 충분히 괜찮은 정도라고 생각한다.
  • js로 변환 가능, js(canvas)도. DOM 셀렉터, 크리에이터 등 DOM 관련 기능이 표준라이브러리에 포함되어 있다.