Command convenience methods for all commands

[mbax]

In #116 the idea of adding methods like newOperCommand to Client was brought up.

I feel the methods already provided for convenience on Channel are useful due to the potentially frequent usage. Operator commands, particularly OPER, are much more special case. Should KICL provided a new*Command in the relevant class for all commands?

[Zarthus]

My personal opinion: no.

Only commands that will be used should be added with convenience, the user should refer to the docs (you could provide a list of all commands) if they want to utilize KICL for it's fullest.

[kashike]

I say yes, only for consistency.

[mbax]

client.newCommand().away().message("Doot doot").execute().

public interface Client {
    // other stuff already here obviously
    class Commands {
        // constructor, set variable client
        public AwayCommand away() {
            return new AwayCommand(this.client);
        }

        public KickCommand kick(String channel) {
            return new KickCommand(this.client, channel);
        }
    }
}

[mbax]

Moving to 2.0 for breaking idea of migrating existing commands in Channel to such a thing too.

[kashike]

public interface Channel {
    class Commands {
        public KickCommand kick() {
            return new KickCommand(this.client, channel.getMessagingName());
        }

        public KickCommand kick() {
            return new KickCommand(this.client, channel);
        }
    }

    Commands newCommand();
}
public interface Client {
    // other stuff already here obviously
    class Commands {
        // constructor, set variable client
        public AwayCommand away() {
            return new AwayCommand(this.client);
        }

        public KickCommand kick(Channel channel) {
            return this.kick(channel.getMessagingName());
        }

        public KickCommand kick(String channel) {
            return new KickCommand(this.client, channel);
        }
    }

    Commands newCommand();
}

?

[mbax]

Something like that, yes. Thoughts?

[Zarthus]

that list would probably be ending up rather long, I see no problem with it but I'd definitely separate commands from client in a new file. I don't think it's the Client's job to have knowledge of all commands defined as an interface.

[mbax]

How many commands are there, such that it'd end up long?

[mbax]

I'm migrating this out of 2.0.0 because I still don't feel this is an appropriate solution.

[mbax]

https://github.com/KittehOrg/KittehIRCClientLib/commit/23b484e9df6fa29bce35611ad1cba770407e2dbe