# Shared Scratchpad # Questions ### Q: where did you start? - lots of clarity comes from seeing an end-to-end flow. - started with modifying an example - what's the smallest change I could make to implement the feature? - insight: "Data Values File" is "just" a collection of `--data-value` invocations - overlays are — in theory — a collection of operations over a document - ### Q: what gave you confidence that the `or_add` kwarg was the "right" approach? - during writing proposal, talked about using overlay functionality as an "implementation detail" for this feature... so why not start there? - we're not going to leak to the user that we're doing this. - this improvement to overlays is something that DK has been mulling over for some time. - alternative approach (if decided didn't want to expose generally), `__or_add_internal` or somesuch. - ### Q: How far into the proposal is this PR? Covering the core feature set: the --data-values-file Does not cover: - required playground enhancements - ### Q: How are you tracking where you are (and what you have left to do)? - I'll come up with a high-level design and try it out. - Sometimes you find out that it sucks for some reason and want to throw it away. - In this case, there weren't a lot of controversial design elements. - As a need arises, look locally for the improvement to existing mechanism - e.g. `@overlay/replace` replaces the entire value; considered `or_add` to extend it to meet these new needs. ### Q: What does "playing around" with a design mean? - one question is, "how can I use the thing, myself?" - exploratory testing... as soon as possible... sketch it out... how does this flow feel... from the user's perspective? - this is about stepping back as soon as there's something running. - for example, I discovered what might happen if the user has trailing comments in a document, it would inadvertently erase the data values. - not using tests to design layers; writing that directly. - bring in tests as risk becomes obvious. when paining (by analogy) - start with pencil "scaffolding" - work in layers of details to add. ### Q: Did you write comments for this review session, or do they help you keep context while coding? - over the years, DK himself, has become to value comments more. - they give the reader "that little nudge" towards understanding the overall flow - want to be able to "speed read" the code, not line-by-line; getting the gist - whitespace can convey "sections" - comments can convey a "heading" of sorts - looking for abstract layers/concepts - put this in for the "reader", not polish for this Tech Forum, session. - will use comments to "pseudo coding" - "Long" methods - in Go, there's quite a bit of boilerplate for error handling - ## Topic: Dependency Injection - whereas in many other places in ytt, we're injecting whole `struct`s, here we're including a few functions. - in `DataValuesFlags` note `EnvironFunc` and `ReadFileFunc` - `iofs` package might be a baked abstraction.