Tags and keywords
This content has been marked as discussing an ADVANCED topic!
Another example using the Webel MArg, MOpt, MFunction, MMethod, MClass and MPackage classes from the HelpM` package, showing how SysMLv1 Blocks can be used to represent the 'opts' Parameter
OptionsPattern[] for each new function for creating objects of each MTools class:
For reference, an associated Policy Note (you don't need to visit this link yet):
The options group strategy and the "Mathematica
Join as SysML Generalization" strategy both have some pros and cons, both for the Wolfram Language coding and the SysML modelling. It is mostly of advantage when there are a lot of options, and where subsets of the options are shared by some (typically "private") functions:
- Pro: Cleaner options management, especially where options are propagated from one function to another (both in the coding and SysML modelling).
- Pro: Options groups can leverage a Webel ODR Map (Options, Docs, Rules) Association or an AOR Map (Arguments, Options, Rules) Association via the '$k$wl$opts' key (explored in detail in later slides).
- Con: In SysML have to "unpack" each option in the 'opts' group in Activity Diagrams using ReadStructuralFeatureAction (corresponds to
OptionValue[]), but this has the advantage Pro: that it makes it clear where propagated options are eventually used. - Con: When using an AOR Map via the '$k$wl$opts' key AND when using "Mathematica Join as SysML Generalization" directly on options groups they can get out of sync with their corresponding AOR Map Associations (the solution to which is to use merged AOR Map Associations instead of Join on options groups).
- Con: If coding in an IDE, one sometimes has to remember what the options for a function are (because they are "hidden" in an options group), but it's easy to check using Options[] in a notebook.
Join as SysML Generalization" approach for OptionsPattern[] groups modelled as SysMLv1 Blocks later in this trail: