Adoption of Name=Value in Function Calls what is best practice?
29 visualizaciones (últimos 30 días)
Mostrar comentarios más antiguos
Jon
el 5 de Feb. de 2024
Comentada: John D'Errico
el 6 de Feb. de 2024
Since R2021A there are two syntaxes available for passing name-value arguments.
There is the traditional, comma separated syntax, for example:
z = foo(x,y, "age",23,"animal","cat")
and the new name = value syntax, for example:
z = foo(x,y,age = 23,animal = "cat" )
My question is, when writing new code, when calling functions that use name-value pairs, should I switch over and always adopt the new name = value syntax?
What would be considered best practice in this regard? Seems like it might be a good idea to change with the times and use the newest approach, but not sure.
Since both approaches still work, perhaps this is just a matter of taste, and there is no right answer, but I'd welcome guidance on whether to make this transition.
2 comentarios
Stephen23
el 5 de Feb. de 2024
A little bit of experimentation shows that the new name=value sytnax is just some syntactic sugar, in actual fact the values are still provided to the function as text + value, e.g. as separate "name",value inputs or as structure fields:
myOne("hello",pi, world=sqrt(2))
myTwo("hello",pi, world=sqrt(2))
function myOne(varargin)
varargin{:}
end
function myTwo(inArg)
arguments
inArg.hello
inArg.world
inArg.unused
end
inArg
end
It is unclear if there is any performance benefit/disadvantage to this syntactic sugar.
Walter Roberson
el 5 de Feb. de 2024
I figure that there must be a slight performance penalty when parsing arguments blocks. On the other hand, arguments blocks get automatically detected by the function signatures mechanisms for editing purposes, which is an advantage at edit time.
Respuesta aceptada
John D'Errico
el 5 de Feb. de 2024
Editada: John D'Errico
el 5 de Feb. de 2024
What is best practice? I kind of like the new syntax. But best practice would seem to be whatever you like. At some point, might the older style be phased out? My guess is since the new syntax is just converted on the fly to the old syntax, you will be ok for the forseeable future. Anything could happen in the future though, and my ability to see the future is rarely good.
It was never valid in the past to use the var=stuff syntax in MATLAB. And you cannot just use it at will on any function. For example...
help prod
A = magic(3)
prod(A,dim=2)
As shown by @Stephen23 (in what I feel should have been an answer) all if does is convert what you passed in into a name-value pair. For example, in my SLM toolbox, which was written before many of the people on this forum knew how to spell MATLAB, it assumes name-value pairs. As such, my slmengine tool has no ability to directly recognize the name=stuff syntax, and before the syntax was introduced, it would have failed. But it does work now:
x = rand(1,5);
y = rand(1,5);
slmengine(x,y,knots = [0 .5 1])
ans =
struct with fields:
form: 'slm'
degree: 3
knots: [3×1 double]
coef: [3×2 double]
stats: [1×1 struct]
prescription: [1×1 struct]
x: [5×1 double]
y: [5×1 double]
Extrapolation: 'constant'
It works just fine. Note though, you cannot mix your call. So this fails:
slmengine(x,y,knots = [0 .5 1],'plot','on')
Error: Unsupported use of the '=' operator. To compare values for equality, use '=='. To pass
name-value arguments using the name=value format, provide these arguments after all other inputs.
Related documentation
Even though this call did work properly:
slmengine(x,y,knots = [0 .5 1],plot = 'on')
1 comentario
Cris LaPierre
el 6 de Feb. de 2024
Editada: Cris LaPierre
el 6 de Feb. de 2024
Minor correction. You can mix your syntaxes but, as the error message states, the name=value syntax must be at the end.
y = rand(1,5);
plot(y,"Color",'r',Marker='*')
Más respuestas (3)
Cris LaPierre
el 6 de Feb. de 2024
This really comes down to personal preference. They are all equivalent syntatically. Name=value syntax can feel more familiar for some due to their experience with other programming languages. Just keep in mind that, as a new syntax, it may not be available everywhere yet.
2 comentarios
John D'Errico
el 6 de Feb. de 2024
Thanks for the observation that the name=value appproach must happen only at the end, if you are going to mix modes. Personally, I can't imagine why one would do that. Using both styles in one call seems a bit silly, even though I tried it myself to see what would happen.
My guess is the name=value style will win in the end, but it may take years for some of us to change over. Inertia is always present, and more so in those of us who have been using the old style for decades now.
Catalytic
el 6 de Feb. de 2024
Editada: Catalytic
el 6 de Feb. de 2024
One situation where you have to stick with the old style anyway is when you want to pre-package your name value pairs in a cell -
line_args={'LineWidth',2,'Color','red'};
plot(rand(1,7) , line_args{:})
You can't do this -
line_args={LineWidth=2,Color='red'};
plot(rand(1,7) , line_args{:})
2 comentarios
Cris LaPierre
el 6 de Feb. de 2024
Correct. In this case, you are first creating a variable, and the assignment operator would be misinterpretted.
Matt J
el 6 de Feb. de 2024
Editada: Matt J
el 6 de Feb. de 2024
@Catalytic You could write yourself a simple 1-line function to handle that kind of situation. Might be worth implementing it as a permanent mfile for yourself.
nvp=@(varargin) varargin;
line_args=nvp(LineWidth=2,Color='red');
plot(rand(1,7) , line_args{:})
Ver también
Categorías
Más información sobre Startup and Shutdown en Help Center y File Exchange.
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!