Added new features to Files.java, fixed issue

[ojles]

Important changes in jterm.command.Files:

• fixed md() (issue "dir md dirName" does not create the directory in the correct location #73)
• added move() method, that was requested in roadmap
• updated delete() and read() methods. I'm using java.nio.* instead of java.io.*. The code just looks more cleaner
• added a wrapper class FilesCommand that has minOptionsSize, helpInfo fields and overridden method accept() that makes checks for minOptionsSize and prints help info if requested.

Minor changes to Jterm.java

This PR is not recommended to be merged (except bugfixes).
I just wanted to say that in my opinion we should somehow generalize the command execution, because it's a bit annoying to read/write code when in each method you have to check the options list for -h option or if it is empty.

Before:

public static void read(List<String> options) {
    if (options.contains("-h") {
        System.out.println("A long help info about read()");
        return;
    }
    if (options.size() < 1) {
        throw new CommandException("To few arguments for read");
    }

    // do read stuff
}

After:

public static void read(List<String> options) {
    // options are already checked
    // do read stuff
}

[Sergix]

I think most of the option checking functions should be put into the new Command interface that you built; perhaps have an inherited options function that is called by execute? I'm not really sure how to have some option-checking code auto-execute without explicitly calling it. But I definitely agree, we do need a better system.

Also, what do you mean by:

This PR is not recommended to be merged (except bugfixes).

[ojles]

Also, what do you mean by: This PR is not recommended to be merged (except bugfixes).

That it is not the best solution for options checking

[Sergix]

Ok.

[ojles]

OK, I have two ideas:

1. We can just hard-code those methods into a Map<String, Command> and the command class will have helpInfo and minOntionsSize. I think it will not be a huge problem.
2. Or we can use reflection to load methods that will have an annotation like this:

@CommandAnnotation(name = { "rm", "delete" }, minOptions = 1, helpInfo = "help")
public static void remove(List<String> options) {
    // ...
}

The disadvantage here is that the helpInfo might be very long and it will not look very good.

[Sergix]

I think the first idea sounds easier, but on the other hand the second option looks much cleaner and would be more readable. What do you think would be best?

Personally I'm leaning towards 2.

[ojles]

I think we can try the second one.

[Sergix]

Sounds good. 👍

I would like to merge the fixes you made, but you might have to create a new branch with those specific fixes and open a new PR, as I can't select the specific commits I want to merge.

[ojles]

Ok. BTW, can we chat in slack ?

[Sergix]

Sure, if it's convenient for you! 😀

[Sergix]

I'll go ahead and close this PR and wait for you to move the changes over.