Timeline for Options in function definition not working with a second set of square brackets?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 14, 2020 at 21:32 | vote | accept | CommunityBot | ||
| Jul 14, 2020 at 12:00 | history | tweeted | twitter.com/StackMma/status/1283008352331665412 | ||
| Jul 14, 2020 at 9:37 | answer | added | Sjoerd Smit | timeline score: 2 | |
| Jul 14, 2020 at 7:21 | answer | added | Natas | timeline score: 2 | |
| Jul 14, 2020 at 7:16 | comment | added | Natas |
Re SubValues have a look at Section 2.2.5 Composite variables and SubValues of Leonid Shifrin's excellent book.
|
|
| Jul 13, 2020 at 20:19 | comment | added | user73765 |
PS: What exactly are SubValues?
|
|
| Jul 13, 2020 at 19:38 | comment | added | user73765 |
Unfortunately it would be impossible to avoid this syntax without rewriting the entire code from scratch. I'm considering simply "simulating" options by looking for explicit patterns in the form of option->value and then parsing the options manually. Is there any simple / built-in way to do so without using OptionsPattern[]?
|
|
| Jul 13, 2020 at 19:18 | comment | added | Natas |
I believe that this cannot be achieved. For the example you provided one could additionally define g[OptionsPattern[{}]] := OptionValue[a] and then g[][a -> 1] "works". I think it is generally advised to stay clear of SubValues (which g[x][y] implies). Is it possible to refactor the function?
|
|
| Jul 13, 2020 at 18:18 | review | First posts | |||
| Jul 13, 2020 at 19:56 | |||||
| Jul 13, 2020 at 18:13 | history | asked | user73765 | CC BY-SA 4.0 |