Skip to content
Hallway
0:00 / 0:00

#kotlin#romanelizarov#namespaces

A Look Into the Future by Roman Elizarov

JetBrains

236K subscribers • 29 videos on Hallway

YouTube
  • Recommended by 1 person: 1 in engineering communities.
  • Presented by Roman Elizarov, Kotlin Project Lead
  • Made by the vendor. The company whose product it covers made or sponsored it.
  • May be out of date. The tools, versions or practices it shows have likely moved on.

Intermediate. Assumes working knowledge.

17K views6 years ago1 recommendation

Programming languagesKotlinLanguage design and type systems

Roman Elizarov discusses the history, short-term plans, and long-term design directions for the Kotlin programming language.

Recording brought to you by American Express. americanexpress.io/kotlin-jobs In this talk, we take a quick look at the history of the Kotlin language, discuss the short term plans for the language, and indulge in some speculation about the future of the language. – what the Kotlin community is interested in and what features we might or might not have in the language in the future. During production of our recorded presentations we followed all applicable public health and safety recommendations to protect our staff from possible transmission of COVID-19. Category: #Kotlin

Why it's here

1 person recommends this

What people say. Engineers point to this talk for insights into upcoming Kotlin features like namespaces.

Moments people linked to

u/dayanrubenin r/Kotlin • Recommends

A Look Into the Future by Roman Elizarov
71View on Reddit

u/cris_nullin r/Kotlin • Mentions

What do you think about upcoming namespace keyword? Outside of classes, I can either declare functions as top level, or put them inside an `object`. Personally I really `object`, to me it just makes everything way more readable. In this talk about the future of Kotlin it seems that they will address this with `namespace`. The reasoning is that some people (like me) use `object` just to create a namespace, but don't care creating an instance or a type of that object. To me, this just seems so perfect! I don't know much about how Kotlin releases, but I searched for "kotlin namespace keyword" and couldn't find much about this topic. I was wondering when could I expect this feature to come…
24View on Reddit

u/elizarovKotlin teamin r/Kotlin • Mentions

On “Kotlin Team AMA #2: Ask Us Anything”

There's no easy to bring companion object (instances) to 3rd classes that did not define one. Fortunately, many use-cases that people have in mind of this kind of "companion object" don't actually need any sort of companion object instance. We have some ideas of how to solve those use-cases which I've outline in my recent talk (timecode pointing to a specific segment): [video You also welcome to track the corresponding issue: https://youtrack.jetbrains.com/issue/KT-11968
13View on Reddit

u/JazzWillFreeUsAllin r/Kotlin • Mentions

On “Kotlin 2.0 - Hypothetical features”

Replacement of companion objects with namespaces.
12View on Reddit

u/Human102581162937in r/Kotlin • Mentions

On “Suggestion: a builder method keyword”

I'd personally be against dedicated syntax like this because it sounds like bikeshedding. I've found that just using `apply {}` is plenty fun builderFun()/*: Builder*/ = apply { // ... } Kotlin also tends to prefer using builder DSLs over fluent interfaces like this. The only big library I've seen using them is Jetpack Compose with its `Modifier`s Besides those though, there's an idea that was considered for decorators: youtube With the decorator syntax something like this *might* be possible: inline decorator fun <T : Any> T.builder(block: () -> Unit): T { contract { callsInPlace(block, InvocationKind.EXACTLY_ONCE) } block() return this…
5View on Reddit

u/MisterScalawagin r/Kotlin • Mentions

On “Companion Objects: Kotlin’s most unassuming power feature”

link to this video not exactly, but this is their solution to a lot of people asking for static stuff
4View on Reddit

u/abreslavKotlin teamin r/Kotlin • Mentions

On “Kotlin Team AMA #2: Ask Us Anything”

I'll hand this over to /u/elizarov P.S. Here's Roman's talk giving a lot of details about how to contribute: **[video
3View on Reddit

u/8bitlivesin r/Kotlin • Mentions

On “What is the best practice for grouping related methods and variables?”

They were pitched about year ago (link to this video), together with the idea of _multiple receivers_, which just got the very first sneakpeek release. So maybe shortly, maybe in another years time. I don't if there is a better road map or timeline yet
3View on Reddit

u/elizarovKotlin teamin r/Kotlin • Mentions

On “Kotlin Team AMA #2: Ask Us Anything”

We are actively looking at all the use-cases that motivate KEEP 87, other similar KEEPs, and issues. In our short-term road-map, we have work on prototyping support for multiple-receivers that could cover most of those use-cases. I've outlined a general direction which this prototype is exploring in my recent talk (timecode links to the proper section): [video You are also welcome to follow https://youtrack.jetbrains.com/issue/KT-10468 We'll post updates there.
2View on Reddit

u/rokkerbociin r/Kotlin • Mentions

On “The state of JVM desktop frameworks: Jetpack Compose for Desktop”

Yes, here it is: link to this video At minute 37 I think, but the whole talk is interesting.
2View on Reddit

u/edrd-fin r/Kotlin • Mentions

On “Kotlin roadmap updated”

It says "namespace-based solution **for statics and static extensions**", which is probably what was proposed in Elizarov's "A Look Into the Future". Doesn't mean they will add first-class namespaces like in C++/C#.
2View on Reddit

u/StandAloneComplexedin r/Kotlin • Mentions

On “Looking for a specific Kotlin talk”

You're welcome. This is also a topic of interest of mine. I've just came across this talk I never watch before: \A Look Into the Future by Roman Elizarov\. It seems to be what you're looking for.
2View on Reddit