This should fix a category of issues where we cannot distinguish user intentions. For example, the first argument of Evision.applyColormap/2 is always expected to be an Evision.Mat.maybe_mat_in(), and the second argument can be either
an integer, or
an Evision.Mat.maybe_mat_in() but with some constriants (tables of size 256)
However, as we allow numbers to be implicitly converted to a cv::Mat, we would always match the first overload function
in the generated code, and the second argument will be passed as userColor instead of colormap.
def applyColorMap(src, userColor, opts) when (is_struct(src, Evision.Mat) or is_struct(src, Nx.Tensor) or is_number(src) or is_tuple(src)) and (is_struct(userColor, Evision.Mat) or is_struct(userColor, Nx.Tensor) or is_number(userColor) or is_tuple(userColor)) and (opts == nil or (is_list(opts) and is_tuple(hd(opts))))
do
positional = [
src: Evision.Internal.Structurise.from_struct(src),
userColor: Evision.Internal.Structurise.from_struct(userColor)
]
:evision_nif.applyColorMap(positional ++ Evision.Internal.Structurise.from_struct(opts || []))
|> to_struct()
end
@spec applyColorMap(Evision.Mat.maybe_mat_in(), integer(), [{atom(), term()},...] | nil) :: Evision.Mat.t() | {:error, String.t()}
def applyColorMap(src, colormap, opts) when (is_struct(src, Evision.Mat) or is_struct(src, Nx.Tensor) or is_number(src) or is_tuple(src)) and is_integer(colormap) and (opts == nil or (is_list(opts) and is_tuple(hd(opts))))
do
positional = [
src: Evision.Internal.Structurise.from_struct(src),
colormap: Evision.Internal.Structurise.from_struct(colormap)
]
:evision_nif.applyColorMap(positional ++ Evision.Internal.Structurise.from_struct(opts || []))
|> to_struct()
end
With that said, this is also the expected behaviour in cases like doing Evision.add(1, 2) where it's expected to convert numbers implicitly (which also follows the conventions in opencv-python).
Therefore, it's necessary to add support for named arguments for all functions so the users can make it clearer which overloaded C++ function they're trying to invoke. The only downside is, we currently cannot pass some positional arguments as positional ones while passing some of these as named one.
This should fix a category of issues where we cannot distinguish user intentions. For example, the first argument of
Evision.applyColormap/2is always expected to be anEvision.Mat.maybe_mat_in(), and the second argument can be eitherEvision.Mat.maybe_mat_in()but with some constriants (tables of size 256)However, as we allow numbers to be implicitly converted to a
cv::Mat, we would always match the first overload function in the generated code, and the second argument will be passed asuserColorinstead ofcolormap.With that said, this is also the expected behaviour in cases like doing
Evision.add(1, 2)where it's expected to convert numbers implicitly (which also follows the conventions in opencv-python).Therefore, it's necessary to add support for named arguments for all functions so the users can make it clearer which overloaded C++ function they're trying to invoke. The only downside is, we currently cannot pass some positional arguments as positional ones while passing some of these as named one.
Related issue: #255