You're using really generic terms which I have to think is mostly because you're talking about it in the abstract. In most scenarios I find there are obvious non-generic names I can use for each step of a calculation.
You're using really generic terms which I have to think is mostly because you're talking about it in the abstract. In most scenarios I find there are obvious non-generic names I can use for each step of a calculation.
I disagree you'd find "obvious" non-generic names easily. After all, "naming" is one of the hardest things in computer science.
I mean, I use `result` in a function named `generate` within a class `JSON < Generator`. Stuff like this is pretty common.
if you're already committing to generic names, what's wrong with a name like `processed_result`?
In the flow he describes you end up with processed_processed_processed_result.
Java mentioned!
AbstractFactoryResultFactoryProcessedResultProcessedResultProcessorBeanFactory
...BeanFactoryContextConfig
First you configure a context, then you can use that to get a bean factory and start processing your whatevers.
That name is kind of redundant, since `result` implies `processed` in the first place.
I think what they're getting at is that they sometimes use composition of functions in places where other people might call the underlying functions as one procedure and have intermediate results.
At the end of the day, you're all saying different ways of keeping track of the intermediate results. Composition just has you drop the intermediate results when they're no longer relevant. And you can decompose if you want the intermediates.
> Stuff like this is pretty common.
Common != Good