I think this might lead to less clean code when dealing with analyzing variadic inputs, requires you to add special cases when another input is after a variadic input, and makes it impossible to differentiate when there are 2 variadic inputs in 1 block.
I propose 2 different solutions to this:
Report an integer denoting how many of the next items are going to be items of a variadic input, then list off the variadic items, kinda like how the join block handles constructing variadic inputs:
Clarifying more about the confusion with block inputs, this is what analyzing a code input looks lke:
So a list property in a splitted block could either mean block input or variadic input, as both are lists.
EDIT: Actually, this won't cause confusion as direct blocks can't be inputs of an analyzed block, only list items representing analyzed blocks.
I’m going to work on this. It will still only work on a predefined list of blocks, but You can edit that list, and I’m going to try to make it differentiate between different variadic slots
Edit: ok, this might be too hard for me
Well, I hope you find something that works for you
I think small-integer-based solutions are kind of kludgy. (I'm not excited about Jens' use of that either.)
There's a profound underlying problem here that I think might entail a redesign of SPLIT BY BLOCKS to solve. A real abstract syntax tree has a nonterminal symbol as the first element of every sublist. We haven't done that because we haven't written a formal syntax for Snap!, but maybe it's time to bite that bullet. So the JS Function example might end up looking like this:
where compound-expression, variadic-inputs, text, and multiline-code are nonterminals. (There would also be a variadic-input-list one.) (It's called compound-expression to distinguish it from literal data such as the text nonterminal.) Somewhere in the formal syntax would be
literal-data ::= text | number | Boolean | multiline-text | multiline-code
expression ::= literal-data | compound-expression
or maybe including "variable" as a separate nonterminal from compound-expression if we decide that a variable reporter is essentially different from any other niladic reporter.
I hesitate to bring up such a major change to this introspection feature at this late date, but better late than never I guess.
it isn't very readable, it has a lot of more complex words like "variadic" "expression" that beginners wouldn't be able to understand at all. i like the current syntax, but i wish it worked with split
Edit:
Using blocks for code instead of text isn’t the standard practice
