Ugh, okay. It's going to be a blast refactoring all my existing code and custom tools to reference this new package.
A big plus for Kotlin is that being a jetbrains project, it has top of the line intellij tooling support right at release date.
With the big investment they are doing in Fuchsia it seem unlikely they will abandon it soon.
Please give us some sources, as to me it's just a project a team there is developing, and so far it can just as well be an experiment with no future.
Android Data Binding does something very similar to Kotlin Android Extensions, which is why it also perplexes me to see experienced devs bind a model to a view and then call findViewById() to alter it. I'll see calls to binding.getRoot().findViewById(), which is crazy redundant.
Just not all clients are open to one more thing for their devs to do/learn. In the specific case for us, the devs were new to Android so they wanted to use a language they were comfortable in.
You won't get the kotlin syntax sugar, of course, but you're not going to be missing any features, either.
Java + StreamSupport + RxJava (and formerly + Retrolambda) is a very modern feeling language.
Heavy use of Optional makes the null safety issues a little less worrying and all my apps are built around AutoValue objects which are a bit like Kotlin data classes.
I'm not sure if I would prefer the second one...
I see extension methods as an inferior substitute for free functions and piping/chaining operators in C#
It is spooky fast and Just Works, in my rather extensive experience with it. Almost all of my experience with it has been in Java, so I'm not sure the same is true in Kotlin though I would assume it would be similar.
Also with functions you know they can't access private members, with extension methods you confuse them with real methods and have to think they can.
It's only the same thing if you know about it and without a tool you can't know, even with tool it takes some inspection.
Also, you need to specifically import the namespace of the extension function in order to use it, making it very clear to the reader of what is going on. It is not some hidden IDE magic, it's built into the core language.
I said it was misleading syntax sugar because it implies that static functions defined in any namespace (extension methods) are the same as methods - which have access to internal members and are defined within class hierarchy.
If you know something is an extension method then you know it's just syntax sugar, but you can't determine that just by looking at the code.
As long as you have good docs, I find discoverability is rarely an issue. One of the first things I do when picking up a language is look through its built-in constructs, to familiarize myself with the available options.
Using autocompletion means you don't have to leave the editor window and I've found it hugely useful for methods which have several overrides - instead of leaving the editor, you just choose the one you need as you type.
At some point I read through the Kotlin docs and found it interesting, but didn't have any projects in mind for it. I might try my hand again along with IntelliJ / Android Studio.
I've happily used other JetBrain products such as RubyMine and WebStorm.
I don't think it's the built-in constructs which are hard to find. In JVM-land, it's sifting through often verbose library interfaces that makes discoverability a huge win. Looking in Javadoc for that single function to convert from Type A to Type B properly can be a real pain.
But even then it's far more discoverable / less overwhelming than "I have a String. I want a Uri. Do I use a UriBuilder, UriParser, Uri, StringConverterFactory, etc?". Not only do you have all classes to choose from, you need to pick the one with the right methods (usually not visible when choosing the class) for the data you have.
Some IDEs can and do improve the helper-classes case a bit by letting you type e.g. `myString.uri` and showing you "uri" methods both on string and static methods anywhere which accept strings... but it's not widespread, sometimes unhelpful (there are far too many "parse" methods), and you're still missing out on the class context which sometimes has important info.
I know C# didn’t do it first, but I’m only old enough to remember C# doing it... and watching people learn the hard way that extension methods pollute the global namespace very easily.
This would be a textbook example of what not to use extension methods for, adding a very specialized extension to a basic type where a simple static utility method would suffice.
> To start using Android KTX in your Android Kotlin projects, add the following to your app module's build.gradle file:
// Android KTX for framework API
And no, there's no scrolling or zooming allowed.
Seriously, let's stop the focus on web framework du jour and actually make web sites that work, please.
That's not to excuse the shitty state of web on mobile, but let's face it: we are talking about completely different teams and priorities.
Looks like it could be fixed by adding a CSS "white-space: pre-wrap" to the <pre> elements they're using to display this code.