You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of the vtkOpenGLTexture.create* methods are starting to accrue many parameters (see #3221 and #3077 changes for parameter additions). Example methods:
This will name every parameter, but also means that leaving out a required parameter might not be as obvious (which can also be an issue with very long positional params, but I don't consider that a fruitful point of discussion for this suggestion).
My vote is for this option, but there is another option to consider.
Optional named parameters
We can instead make only the optional parameters part of an "options" record:
This makes sense for optional params, but we still have the issue with many positionals (e.g. is it width/height or height/width in create3DFilterableFromDataArray(100, 100, ...)?)
Backwards compatibility
These are mostly used internally, so cutting a new major release is a soft requirement.
If we moved these from arrow functions to regular functions, we could detect when arguments.length > 1 and unpack the arguments accordingly.
The text was updated successfully, but these errors were encountered:
Motivation
Some of the
vtkOpenGLTexture.create*
methods are starting to accrue many parameters (see #3221 and #3077 changes for parameter additions). Example methods:I would like to propose changing these methods to use named parameters over positional parameters. (See this comment for more context.)
This issue is for tracking as well as soliciting opinions over implementation approaches and whether this is something to move forward on.
Tagging @finetjul @jourdain @sedghi
Detailed Description
All named parameters
One approach is to move completely to named parameters:
This will name every parameter, but also means that leaving out a required parameter might not be as obvious (which can also be an issue with very long positional params, but I don't consider that a fruitful point of discussion for this suggestion).
My vote is for this option, but there is another option to consider.
Optional named parameters
We can instead make only the optional parameters part of an "options" record:
This makes sense for optional params, but we still have the issue with many positionals (e.g. is it width/height or height/width in
create3DFilterableFromDataArray(100, 100, ...)
?)Backwards compatibility
arguments.length > 1
and unpack the arguments accordingly.The text was updated successfully, but these errors were encountered: