Collectible Card Game Headquarters

I understand that it would be a huge task to perform, but it doesn't all have to be at once, and, properly configured, Kotlin takes away a lot of the unnecessary boilerplate required by Java, making the code easier to understand and therefore debug.

consider the following class, MatchWinStreak:

Code: Select all

package forge.achievement;

import forge.game.Game;
import forge.game.player.Player;

public class MatchWinStreak extends StreakAchievement {
    public MatchWinStreak(int bronze0, int silver0, int gold0, int mythic0) {
        super("MatchWinStreak", "Match Win Streak", null,
            String.format("Win %d matches in a row", bronze0), bronze0,
            String.format("Win %d matches in a row", silver0), silver0,
            String.format("Win %d matches in a row", gold0), gold0,
            String.format("Win %d matches in a row", mythic0), mythic0);
    }

    @Override
    protected Boolean eval(Player player, Game game) {
        if (game.getMatch().isMatchOver()) {
            return game.getMatch().isWonBy(player.getLobbyPlayer());
        }
        return null;
    }
}


With Kotlin, it's re-written like this:

Code: Select all

package forge.achievement

import forge.game.Game
import forge.game.player.Player

class MatchWinStreak(bronze0: Int, silver0: Int, gold0: Int, mythic0: Int) : StreakAchievement("MatchWinStreak",
        "Match Win Streak", null, "Win $bronze0 matches in a row", bronze0,
        "Win $silver0 matches in a row", silver0, "Win $gold0 matches in a row",
        gold0, "Win $mythic0 matches in a row", mythic0) {

    override fun eval(player: Player, game: Game): Boolean? {
        return if (game.match.isMatchOver) {
            game.match.isWonBy(player.lobbyPlayer)
        } else null
    }
}


And while that's not much of a code difference (I literally just picked the first one that looked complex enough to show code differences and converted after the fact), it does still manage to make it easier to parse. No longer do you have to read the String.format params for instance; just inline the variable in the string (if it's a method/property call the only difference is adding curly braces). Call properties directly like a normal language; they can be made to be read-only or internal or private, after all. Return conditionals (the coolest version of this is "return when", IMO). Lots of other stuff, too: I can't link out because this is possibly my first post on here, but "docs/reference/idioms.html" on the kotlinlang website has tons of stuff that makes Java coding easier as long as you're not actually using Java.

It might help to point out that IntelliJ IDEA (and its derivatives, the Community Edition and Android Studio) can convert Java to Kotlin out of the box, as well, which should make some of it less painful to do.

I personally would be all for this, but at least a few of the other developers have expressed disinterest in learning/using Kotlin for the project. For now, it's likely that it will stay vanilla Java.