I can't figure out the cases block coding. Help
HI, welcome to the forum!
Use the arrowheads at the end of the CASES block to make more input slots, and fill them with ELSE IF and optionally ELSE.
I was wondering about this as well and did some testing after reading @bh description.
Here is what came out:
Case logic NEVER prints the else case and runs twice as slow as the equivalent IF/ELSE.
IF ELSE logic prints the final ELSE case every time and runs twice as fast.
Is there a bug in the CASE block?
no. I am a new Snap! user and so I downloaded the libraries recently; your first reply did the most good and the other response that said the if else control works faster than the case block provided by the other forum member was quite useful to have too.
sls
Thank you. Although, for now speed doesn't effect what I am doing now.
sls
I was asking @tguneysu if he had an old library, because I can't reproduce his bug.
About speed, IF/ELSE is a primitive block, while CASES is written in Snap!, so it's not surprising that the former is faster.
I opened the online SNAP! and loaded the library from the LIBRARY menu option. No idea about versions.
OK guys,
Please accept my apologies.
I loaded the library and then deleted the Catch & Throw blocks which I never use. But it so happens that the Case blocks used it. So, in a way it's my BAD !
However, should there not be some sort of dependency check for these library blocks ?
I don't know if I am the only one who loads a library for a few blocks and gets a bundle. So I regularly delete stuff I do not use. And yes, I don't have a habit of looking inside each and every block and seeing if it uses anything I have deleted.
I am not saying this to justify what I did, but given the audience range of users, some sort of block code integrity check has to be present in the libraries. At least, when the used blocks are deleted, there could be some special block inserted that indicates the change.
In my case, the addition of the libary and the deletion of the catch & throw happened back to back. I did look inside the case block to see if I would notice something. But all I saw was an empty else block, because it was already too late !
Anyway, sorry again for raising the blood pressure; but I think there ought to be an integrity check for library blocks, instead of pure deletions without a trace !
If you explicitly deleted catch and throw from the palette, we kind of have to assume you know what you're doing, I think. I mean, I guess when you delete a block we could say "that block is used here, here, and here; are you sure?" since we have to find that out in order to delete the victim from those scripts. But to give the warning we'd have to scan all the scripts twice. On the third hand, maybe it's okay if the UI act of shooting yourself in the foot is slowed down.
Anyway, that goes in the "good idea but don't hold your breath" category.
What I've been pushing for a long time now is that the Delete Unused Blocks list should compute the transitive closure of the used blocks, so you can't get in trouble through that route. If I talk Jens into that, then you should get in the habit of using Delete Unused Blocks instead of doing it by hand.
But also, we have to work on the whole question of scope of procedures, so that a library can hide the blocks that it's loading as helpers. Then you wouldn't be tempted to delete them.