(Trivial) Show crate use more clearly in example - #32

I'd rather see this imported like this, which is how I would write it:

use ringbahn::drive::demo;
use ringbahn::event::Read;
use ringbahn::Submission;

(Wall of text. Perhaps I've put a lot more thought to this than it needs. It had me thinking, though, and I went into the blog-writing mindset 😖. Perhaps I enjoyed digesting the nuances at play a bit too much 😅)

I agree in the context of writing production/personal code. Normally I would do the same. For this PR, I had a different context in mind when I made this style choice. I was reading the example as first-look at how to use this library, looking to get a big-picture understanding. I think this difference in context is key. To illustrate how this motivated my decisions:

• I see function calls without namespacing
• I see glob import of ringbahn
• I make the assumption that it falls under ringbahn
  • Having that wild card there somewhat obfuscated the big picture.
• I fork+clone, deleting the import, and build the example. Compile errors clear up my assumptions and help me see things in a big-picture context. (I could have gone to docs.rs. In this case, I anticipated wanting to make a PR, so I went with a fork+clone)

I have a lot of respect for your approach to subjective matters. If the following arguments are constructive, your consideration of them would be appreciated.

I can certainly see that your approach holds merit in the general case of example code, particularly in that it's consistent with good production style. For this example, however, I argue we have an edge case and that warrants this style adjustment.

• The separation between import and its subsequent use leaves a "cognitive distancing" between use of one part of an API, and understanding the bigger picture of the API. A significant motivator behind writing good examples is to equip the reader with this big picture: reducing cognitive distancing becomes much more important.
• To expand on that point, introductory teaching material leaves much less room for many assumptions about the target audience. In this case, one of them is the line between Abstraction and Obfuscation, and what is in effect "noisy" and what is "obvious".
  • This can be difficult to judge. My position is that it's better to err in favor of being sufficiently obvious to the audience over noise reduction in cases such as this.
• Each import is used just once. This reduces the value of having a deep namespace import file-wide.
  • To me, without a function being used multiple times, in a file that might not provide much contextual information, important big-picture context is missing. Putting in the namespace prefix fills this gap, and doing so just once leaves minimal added noise.

The choice is inescapably of an opinionated and subjective nature. I've read some of the your write-ups on such issues (and re-read Not Explicit), and I have a lot of respect for how your mind works with them. I'll be satisfied whichever choice you make. Say the word and I'll change the PR accordingly.

...seems like I let myself go on that. Don't read into it as a sign of how strongly I feel about it. It's as much an opportunity for me to practice articulating my thoughts as it is to add my thoughts to the discussion.