... so I've always admired the variable parameter option in GP (Browser GP) that, IIRC, was programmed up by Jens himself
Now one day, we might get this in Snap! as well but in the meantime, I've come up with this method of just having a multiple inputs parameter as the options parameter
This is what it looks like in the palette
and if no options needed then it can be shrunk
...
The main problem with this approach is that fact that a Snapper doesn't know what the optional parameters are as we can't provide text descriptions
My workaround for this is to include the information in the help box
So this lets Snappers know what extra options they can use.
This all good and it just takes a little bit of extra code inside the reporter to read and respond to the options
But since I originally made this block, I've gone onto do other ones and I decided that I really could do with a method of naming the optional parameters
This is one of the many reasons we need variadic input groups.
Lisp solves this problem with keyword inputs, so you'd say
(text->costume "A" 1 &border 4)
including any number of the keywords in any order. The block-language equivalent of that would be to have a variadic pair of inputs in which the first one is a pulldown menu of keywords and the second is the corresponding value.
Variadic input groups have been on the list for a long time; we all agree we want this feature. We haven't totally firmed up a design for the UI in the block editor, and other things have been higher priority. But we should think about getting around to this soon.
I think what they're talking about, and what you might be as well, is the "with inputs" text of CALL, RUN, and LAUNCH W/INPUTS that doesn't appear if you don't have them in the block.
I no longer remember exactly why we changed that interface in 4.0. I think at that time Jens was skeptical about the whole idea of dropdowns to change the behavior of primitives. (As opposed to dropdowns to change the target of a behavior, e.g., which sprite or which attribute.)
Since then, though he's gone all in on the idea, as in the LENGTH block that turns into half a dozen other blocks via its pulldown. CALL WITH INPUTS vs. CALL WITH INPUT LIST is less drastic a change than LENGTH vs. JSON! So maybe we should revisit that decision When Things Slow Down™.
We now have several ways to distinguish among alternatives in a family of related functions: the original way, to have separate blocks, e.g,. for +, –, etc.; to have a hidden RELABEL option, e.g., for MOD, MAX, MIN, etc.; and to have an explicit pulldown, e.g., for LENGTH, FLATTEN, COLUMNS, etc. I don't think we have any coherent policy about when to use which. The reasons are partly historical (i.e., how does Scratch do it?), partly aesthetic (is a pulldown ugly here?), and partly a sense of just how related or unrelated the functions are. In retrospect we probably should have chosen RELABEL for the LENGTH block, but that would have been less discoverable.
Maybe because no-one would really want a [inputs v]/[input list v] dropdown on all blocks with variadic inputs. (Except for (list < >) , (() >), and |script variables ((a)) >|.)
Oh yeah, that sounds right. At first only primitives had variadic inputs, but pretty quickly we added them for custom blocks too, and that required a notation. The red halo around the arrowheads is my fault, btw.
To use it in a simple way - just fill the first slot with the optional parameters that you want to supply to one of of my options slots and it will simply return the list you supply it
