search

thblt / write-yourself-a-git

Learn Git by reimplementing it from scratch
https://wyag.thb.lt
GNU General Public License v3.0
655 stars 75 forks source link

Library, executable seperation #3

Closed ItsShadowCone closed 1 week ago

ItsShadowCone commented 5 years ago

It's nice how you put your code in a seperate libwyog.py, but consequently, libwyog.py should only "export" (aka define) functions for like init, add, commit, etc and the wyog executable should do command line parsing etc.

thblt commented 5 years ago

Thanks for the suggestion, but I'm afraid implementing this change would make the tutorial harder to follow with no real gain. The point of having two different files is to make sure that the program is runnable at any point of the tutorial without expecting the user to insert new code at any other place than the bottom of the main file. Since Python is a dynamic language, everything must have been evaluated before the main function runs. The only simple solution to insure a clear separation of concerns would be to add a third file libwyagcliargs.py or something, but I'm not really convinced the gain is worth the increase in complexity.

ItsShadowCone commented 5 years ago

Suggestion persists, I have the feeling you don't quite understand why one splits code into a library file and an executable, because *adding code at the bottom so it's less complex" isn't the point. I would think it wouldn't add too much in complexity but after all it's your tutorial.

thblt commented 5 years ago

On 25 Mar 2019, at 07:27, Cl1608Ho notifications@github.com wrote:

I have the feeling you don't quite understand why one splits code into a library file and an executable, because *adding code at the bottom so it's less complex" isn't the point.

I'm afraid you didn't understand my previous reply. Simplicity is not a general, abstract, in-a-perfect-world motivation for separating library and executable, it is the rationale for splitting code in the very context of this tutorial. To be extremely clear, I'd rather have stayed to a single-file approach but I'm afraid it would have made the tutorial harder to follow.

I agree with you that from a code quality perspective, what I do is not good design; but I don't plan on changing it if the change introduces more complexity from the reader's perspective than the present state.

That is to say, I'd be happy to implement any change that would improvise the overall design quality without sacrificing clarity. But clarity, not design quality, is the primary concern here.

If I find the time, I may add an appendix to the document to explain why wyag is structured the way it is. [Note to self: things to explain: the big-elif-switch-why-not-a-dict thing, the classes-as-structs thing and the argument-processing-logic-in-library thing]

Ps: I'm sending this from my phone, I hope it will render correctly on github. Apologies if it doesn't