Drag this image into the editor:
It will import the blocks.
Nice work 
Could you add a default case into it?
A default case would be a great extra feature!
Besides, can you (@coder_07) think of a way to code the whole thing without resorting to metaprograming or Javascript? (I'm not sure leaving out metaprogramming will allow the blocks to look exactly as they are now, but a similar construction perhaps).
I built a somewhat similar block some time ago (and improved it just now):
defined as:
No metaprogramming, no Javascript, no helper blocks 
Here's one with a default case
i've created a monster
I'm very afraid 
The plan is to have the block by itself and have no helper blocks
just fixed a bug with the old default block, re-import it if you used it
It works fine!
Still you may want to look into my recently modified post (#3) for additional ideas,.
Is there a link to a project with showcase of these (I’ll see myself out)
Getting an error with this
weird.
so this is like an if statement but different? cool!
I'm probably gonna make some more custom blocks and put them into a pack
Rather simple but ugly...
Without the variadic multi-part input, or at least the custom reporter as a default input value, it seems impossible to get the desired results without the quirks.
It can be simplified with the dynamic scoping
It's great how you guys are embracing metaprogramming! It's very cute that the CASE block itself does nothing. :~)
You should look at the way we did it in the library, which I can't find in the list any more, but it's still in .../libraries/cases.xml. Long before metaprogramming, a solution that makes CASE a predicate, reporting whether the case was matched, but first doing the action if so.
By the way, your FOR EACH that goes through all the CASEs is a good candidate for a CATCH/THROW pair that would THROW to the end of the SWITCH code if it finds a match, so it doesn't even have to consider the remaining clauses.
The former CASES block was removed from the “Iteration …” library when
(which can do anything CASES could)
was introduced in Snap! 9.
My point: keep library blocks (at least the ones with interesting features “under the hood”) for reference - not in some hard-to-find folder where only the nerdiest among Snappers may look, but in plain sight, i.e. within a library that is part of the development environment. Studying the definition (and implementation) of a function can be quite instructive, and even inspiring, for students and aspiring programmers.
If you (the Snap! team) are against library blocks doing the exact same thing as a (newer) primitive block, I propose two alternative options:
- Enhance, or develop a variation on, the library block. In this case () e.g.: a built-in “default” branch (enhancement) or a reporter version (variation).
- Create a dedicated library for interesting now-obsolete blocks that used to be in one of the regular libraries.
It is our intention (no promises on the schedule) to write in Snap! itself every primitive that can be so written (modulo making things too slow, see below), and to make primitives editable, letting you make a new version with different behavior. If doing some primitive in Snap! would be too slow, we'll use the PRIMITIVE block to write it in JS, so that the primitive has a trivial Snap! definition that just calls PRIMITIVE. I'm hoping that in those cases there will also be a real Snap! version as part of the primitive's structure, so users can edit that version to do the kind of learning you (and we) want.
OTOH we also want to make Snap! itself fast enough so that kludgy JS primitives aren't necessary for speed. Using hyperblocks on big arrays is already pretty close!
So anyway, yeah, give us time, we're on the same page.
We can all see the development team making good progress in speeding up Snap!
And of course it takes time to implement all of the (undoubtedly excellent!) ideas on making primitives more transparent and editable. Even so, wouldn’t my suggestion to keep (or restore) now-obsolete library functions (within a special “museum” library, if you like) be a quick win?