For example

so what do you want to catch? you will only get an exception if the value returned by

get

is not a

Map

to handle that situation, you can for example use

as?

instead of

as

It still wants me to make the type

Map<*, *>

there is nothing to catch

the compiler shows the warning because there is no way to check at runtime that you have a

Map<String, Any?>

and not a

Map<Foo, Bar>

hm

therefore, if you do have a map that has a different key and value type, you can get a

ClassCastException

when you try to get a value out of the map

normally you just need to suppress the warning if you know that the map will not have a different key and value type

this is exactly the same as in Java

Thanks simple smile

Kotlin 1.0 Beta 3 is Out! We are glad to present another update of Kotlin 1.0 Beta. We are working towards finalizing the standard library and getting rid of old deprecated constructs in the language, as well as bug fixes, performance improvements and future-proof checks. Full … Continue reading →

https://twitter.com/kotlin/status/673839744401428480 Kotlin 1.0 Beta 3 is Out! http://blog.jetbrains.com/kotlin/2015/12/kotlin-1-0-beta-3-is-out/ Twitter

Are there any chances that classes may be open by default in a coming beta or in a future release?

nope, they're final by default due to valid design considerations.

Which is a grand idea

This is why: https://kotlinlang.org/docs/reference/classes.html#wait-how-will-i-hack-my-libraries-now

Well I’m not so much into hacking libs as more into frameworks that use proxying (e.g. Spring/Hibernate) which will break if you forget to mark all the classes you want to use with the framework as “open”. And as a bonus these things will only pop up at runtime. I can see the reasoning behind the decision, but it’s at least inconsistent to have a thing like “everything is public by default” which is inspired by pragmatism and then something like “everything is final by default” which is more inspired by a “best practices” approach (to which you may or may not subscribe). But okay, so I no longer need to write “public” everywhere instead I now just write “open” everywhere. One thing gained, one thing lost, so it’s break/even for me simple smile

I guess in the future we will get a few more Spring inspections which will mark your classes if you forget to make them “open”.

Which is ok for me.

Yep, I encountered this problem with Spring too at some point, and my thought process was the same simple smile

one thing we’ve discussed is adding an annotation or modifier like @AllOpen, which will mark the class and all of its members as open

I have found myself into the issue of open classes on Spring, but the framework fails fast telling

final

keyword on classes are not supported, after a day it became an habit to put

open class

on components, maybe documenting what classes without

open

will be interpreted like

final

can give some idea on what is going wrong.

I’d like the modifier approach, it’s a bit like the

data class

thing. And you wouldn’t need to put it on every method, which is a plus.

Just letting people know, Kotlin is now my companies primary language

I actually don’t like the idea of any modifier (

@AllOpen

included) on the class level influencing the behaviour of the function level. I think that’s even more confusing.

how about @SuppressWarnings, for example? it exists today

I always try to put in on the method or statement

because putting it on the class can lead to bugs