This is like JavaScript’s Array.prototype.splice, but completely implemented in Snap!.
This is the block:
This is the block:
nice block! I can’t drag and drop however because of the poor mobile device. Bummer..
Good project! I only have one suggestion, which is that I think it should be a reporter.
Why? Although it technically has a return value, it’s more often useful as a command block.
I’m not sure I’m reading @sathvikrias’s mind correctly, but my own inclination would be to make it a reporter that doesn’t modify its input.
(I didn’t bother with the “putting removed items in” part because this block doesn’t actually remove anything from the input list.)
Yes, certain algorithms run a lot faster if you modify your input; quicksort comes to mind. But purely functional code (no assignment, no mutation) is generally much easier to understand and debug.
If you program functionally, it makes sense to write reporters rather than commands, all the time! If not, the argument for any particular block to report a value is less compelling.
P.S. Yes this has a bug if start index=0, but I prefer to think of this as a bug in the NUMBERS FROM block. :~)
Yeah. although that block is criminally long.
item (all but first of (numbers from (0) to ((index)-(1)))) of (input)
from my time using snap, I disagree. Especially in the case of map (()@>) over @list (and the other HOFs), command blocks get really annyoing to work with. Even if it was sometimes more useful in a command block, you could always put a reporter in the set variable block to do more or less the same thing.
Fair enough. I will keep it as a command block, but there should be non-mutating versions of all the mutating ones (INSERT, DELETE, REPLACE). Probably in a library, but I shouldn’t ask too much
I have them here if you want to use them: