! this is a work-in-progress / not to be used in your own projects
create a new project or just stay in this one.
just like the script variables block, but has a variadic input where each ( var = val ) segment is 1 arrow click (shift-click works too, for 3 lines at a time). requires js.
working on a way to be able to use in projects without requiring the user to select enable js, where when you save / load the project it reverts to original multi input slots but retains functionality and should be able to revert back to this version through another js invocation. that is, optional in the editor, but not required for user.
I think it's a little strange that in the three-variable example the a*b block is in a ring, but the function is invoked, while none of the other value slots are ringed. To be consistent the constants should be ringed too. This is why we invented the "unevaluated" input types. You should use "Any (unevaluated)" as the type for those slots.
And yes, we know we need variadic input slot groups. But for now there's a pretty good workaround used in the Multi-branched conditional library.
i was puzzled by that too. they actually are unevaluated input slots, I tried it a few different ways and this was what just what happened to work. at first I was trying to put the a * b in without the ring because that's how it usually works
var a = 3,
b = 4,
c = a * b;
but it won't take the operator without the ring without evaluating it, even in the unevaluated slot. so they're all unevaluated which makes the normal number/string inputs need a call block and the ringed reporter with previous variables gets passed as is, also needing a call block.
and until you guys add what I want, I'm just gonna try to make it myself. sorry I'm not sticking to strictly 'built-in' methods but put me in a box I'll find my way out one way or another
also I don't like the library version just because they nest into each other, so if you have 6 or 7 else branches (which really isn't that many) you get this layered indentation which is unappealing and counterintuitive. not to say it isn't a clever trick but not something I would use past that initial 'checking it out' phase
Hmm, I can't make sense of what you said, so either I'm misunderstanding you or you're misunderstanding me. In case it's the latter, here are pictures:
i changed the .addInput method on the multi arg so that it has an inner function (I think its just .add(spec)) which I can call inside the function multiple times for differents specs.
similarly for .removeInput(), I put another inner function to remove a specific number of elements.
pop(4);
I didn't bother updating the slotSpec property. it didn't really cross my mind.
+edit now that i think about it, it wouldn't make much sense with the current interface to have just one input option selected, as theres both upvar and any (unevaluated) slots used.
and yes, that if-else block would be much cleaner with a multi-cslot input with some 'else if' labels and boolean slots in between. that is a little different than I remember though maybe I was thinking of something else.
The only real difference is that there's a newline between branches in your version, whereas the library version allows two branches on a line if they're narrow enough.
Of course it'll be much better when we have a notation for variadic input groups, but I'm just saying that meanwhile we have a pretty good workaround.
yeah and I don't mean to split hairs but it is a note worthy difference to me, I like having my code organized and clean, that 2/line thing bothers me as well as the yellow background behind the cases.
maybe kinda like that italic m thing you don't like, :~P
=> 
=> 
=> 
=> 
. . .