General
Follow


Evolution of arguments-block functionality

Steve Eddins on 2 Dec 2024
Latest activity Edit by Adam Danz on 3 Dec 2024

I wish I knew more about the intended evolution of the capabilities of the function arguments block. I love implementing function syntaxes using this relatively new form, but it doesn't yet handle some function syntax design patterns that I think are valuable and worth keeping.
For example, some functions take an input quantity that can something numeric, or it can be an option string that descriptively names a particular value of that quantity. One example is dateshift(t,"dayofweek",dow), where dow can be an integer from 1 to 7, or it can be one of the option strings "weekday" or "weekend".
Another example is Image Processing Toolbox that take a connectivity specifier as input. The function bwconncomp is one particular case. Connectivity can be specified using certain scalars, certain arrays, or the option string "maximal".
I think this is a worthwhile function design pattern, but I don't think the arguments block validation functionality supports it well (unless you use a lot of extra code that duplicates standard MATLAB behavior, which undermines the value of the arguments block).
I posted about this today over on my blog. See "Function Syntax Design Conundrum."
MathWorkers - believe me, I know that it is not in your DNA to discuss future features. But would anyone care to offer a hint about directions for the arguments block functionality?

8 Comments

goc3
goc3 on 2 Dec 2024
That is a great article, Steve. I posted a comment there, but cannot see how to format code in the comments on that site. So, I have included suggested code here, as well, in an easy-to-read format:
function t2 = dayofweek_shift_v4(t, dow)
arguments
t datetime
dow {custom_dow_cheker(dow)} = 1
end
t2 = dateshift(t, "dayofweek", dow);
end
function custom_dow_cheker(dow)
if isnumeric(dow)
mustBeScalarOrEmpty(dow);
mustBeInteger(dow);
mustBeInRange(dow, 1, 7);
else
mustBeTextScalar(dow);
mustBeMember(dow, ["weekday", "weekend"]);
end
end
Steve Eddins
Steve Eddins on 2 Dec 2024
Thanks for your reply and code, Grant. I like your implementation.
I'm still learning my around the Ghost independent publication platform. I'll investigate the issue you had with commenting there.
Michelle Hirsch
Michelle Hirsch on 2 Dec 2024
I spent some time last week updating some of my very old File Exchange submissions. It was a real treat to replace tons of messy complex input arg parsing with function argument validation, but I got stuck on my functions that use the standard graphics pattern of allowing an optional leading input argument to specify what axes to operate on. I've been trying to decide if I should update those functions to make axes a named argument or if I should push to support this with arguments validation. I think your specific request is better motivated and more likely to be achievable without disrupting the current design.
Adam Danz
Adam Danz on 2 Dec 2024 (Edited on 3 Dec 2024)
The leading optional parent argument in most graphics functions is a frequent barrier in graphics land to using the otherwise terrific arguments block.
Another example of arguments that accept both numbers and strings is color properties such as FaceColor=[.1 .3 .2] or FaceColor="flat".
It's easy to get carried away with ideas. Image combining validators using ampersands and pipes instead of commas {MustBeNumeric | MustBeText}
goc3
goc3 on 2 Dec 2024
Actually, I think that the ability to use pipes between validators (for logical OR) is not getting carried away at all. The commas between multiple validators are already performing the same purpose as a logical AND (ampersand).
This would be helpful for many use cases, such as something like this for what Steve wants:
{ ( mustBeTextScalar & mustBeMember() ) | ...
( mustBeNumeric & mustBeInteger & mustBeInRange() ) }
goc3
goc3 on 2 Dec 2024
I have had problems with that specific use case: custom plotting functions that do not require an axes object as the first input, unless they are used in App Designer... It is good to know that all the time I spent trying to get that to work was not due solely to a lack of programming skills on my part.
Also, I am always in favor of increasing capabilities of arguments validation.
Steve Eddins
Steve Eddins on 2 Dec 2024
For new work, Michelle, I've been going with name=value pairs for specifying a parent so that I can use the argument-block implementation.
goc3
goc3 on 2 Dec 2024
That is a great tip!

Tags

No tags entered yet.