30 Days of Rust - Day 12

Happy Friday folks, I've got some time to myself this morning to make some progress on my CLI project. I'm currently en route to Munich from Berlin to attend my company [at]'s spring party. Don't worry I'll make sure to not overdo it so that I can post again tomorrow.

Yesterday's questions answered

• The ? provides a short-hand way of handling Result and Option. If a function or method returns a Result or Option, then chaining that call with ? will cause the function to return if an Error or None is yielded, respectively. These are both wrapped in their respective containers. If the Result or Option yields a value, then the function will continue to execute.
• to_owned is a required method of the ToOwned trait. It is very similar to clone. It basically takes a borrowed value and turns it into an owned one. I'm not sure what the implications for your program would be in this case. I guess I really need to look more at ownership 😀

Today's open questions

• What does &'a mean?
• What exactly is an implementation type?
• What are Send and Sync?
• Is derive similar to class inheritance?

Mistakes have been made

As you may have noticed from my last couple of posts, I've been struggling to make proper progress on my project. This is in part due to my inability to code quickly in Rust. Now as I reflect, however, I also realise that it would have probably been wiser to start with the CLI tool.

The CLI is the point in our program where we define our data models that will be received from and fed back to the user. Initially I feared that starting with the CLI tool could lead to a coupling between the different parts of my code. I have worked on projects where third-party CLI tools were so deeply embedded in a system that you could only run and test Python code from through the CLI (I know, pytest is a CLI tool but that's not what I mean here). I think I was overcompensating here and ran into another problem: designing code without a clearly defined data model at hand. Consider this extract from the CLI section of the Rust book:

"In Rust, it is common to structure programs around the data they handle, so this way of looking at CLI arguments fits very well."

CLI models

I was able to setup a very simple CLI model that accepts a command string as an argument. I used the derive approach from the clap library. This worked well to get something simple working. Where I'm struggling right now is understanding how I can split my command string into CLI arguments. The shlex library should solve this problem, but it doesn't support powershell parsing. One solution could be to use the shell when running on Windows and an argument approach when running on unix.