Open JorySchossau opened 3 years ago
Okay, so just a counter point.
read/write or set/get pairs usually are applied to systems where data is written to the system and then the same data is read from the system.
In defense of the current naming.
So, this language could indicate that this is not a simple read/write or set/get system... Is this a "good" argument? Probably not... but it is an argument.
I think update
is orthogonal to the naming of these setter/getter fields, because I can use them as standard setter/getter fields. I can have a series of complex if
statements setting the input, then before I run update
I can read out the inputs to see what the final input pattern is, possibly save to file, then call update
as usual. So in this way they really do operate like traditional setter/getter fields that write a value and allow you to get the same value back.
I could see renaming update
to computeOutputsFromInputs
to make the relationship clearer. So maybe the following:
setInput()
/getInput()
computeOutputsFromInputs()
/update()
/stepOutputsAndInputs()
getOutput()
/setOutput()
setInput,readOutput
should besetInput,getOutput
orwriteInput,readOutput
for consistency. Probably a consideration for next breaking update.