Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> Regardless of the language the scripted version was written in, I >> think the '--helper' approach is always the poorer choice between >> the two [*1*]. It limits the modular decomposition to what suits the >> original language, the impedance mismatch between the original and >> target language forces us to unnatural style of inter module >> communication, and the unnatural interface layer, which we know has >> to be discarded at the end, must be written [*2*]. >> >> So, I'd prefer to see "because this is a better way in the longer >> term" over "because the --helper approach would not work". > > Hmm. I feel distinctly unheard. The feeling is mutual ;-) > It may appear compelling, conceptually, to shun the `--helper` approach, > but the more important reality is that it is the only one that makes an > incremental conversion possible at all. > > It took an entire month of 60-hour weeks to complete the conversion of > `git add -i`/`git add -p` to C, and only at the very end was I able to > run the test suite with `GIT_TEST_ADD_I_USE_BUILTIN=true` and see it > pass. Yeah, that is developer comfort, and of course it is nice to have than not to have it. But compared to the downside impact to the quality of end result that is inherent to the '--helper' approach, I'd prioritize the quality of the end result over developer comfort. > It is indeed _in spite of_ the success of the `--helper` approach that > we cannot use it here. As I do not see those past '--helper' ones necessarily successes, we must agree to disagree here. In any case, the log message needs to express why _you_ ended up taking the non-helper approach. Even though it is far less relevant, compared to that, what other approach you instead wanted to take, I do not veto you from having your own opinion. >> [Footnote] >> >> *1* In only one case I would recommend using "--helper" approach, >> though. When you are not expecting the developer to be able to >> come up with a better split of the program into modules than how >> the scripted version is, and you want to ensure that the >> developer have something to show when they faild to complete the >> project after N weeks. You are a more experienced developer >> than an average GSoC student, and there is no pencils-down time, >> so the exception would not apply. >> >> *2* In "git submodule" for example it was quite natural for the >> module that gives a list of submodules with its traits the >> program cares about to be written as a shell function that >> writes the data to its standard output. And consuming modules >> sit at the downstream of a pipe, accepting its output. When you >> are writing these modules both in C, you wouldn't connect them >> with pipe to carry the list of submodules, but a piecemeal >> conversion using the "--helper" approach meant that there always >> remained _some_ consumer that wants to read from the pipe, so >> long after the module lister was rewritten in C, it still needed >> to support a mode where it sends its output to the pipe, instead >> of just passing an array of structures. >>
