Add catch and throw to the block pallet already!

They already have their own custom help message as if they are part of the library (more than the pipe block can say) my best guess is because they are directly referenced as an example for continuations, but there has to be another way to explain it better.
Especially since the continuation blocks are getting moved to dev mode it would be a good time to add them. now that the help message inside them would be obsolete, and that the new implementation for them are part of a drop down therefore doesn’t need to be explained in a help message.

?
Something I missed while looking at the dev version ig

Is it really that hard to click a few buttons to get the blocks?

Yea but they are deprecated now and most people don’t know about that
They are being replaced with the better “(this [continuation v])” block that also has “(this [script v])” and “(this [caller v])”
They would also still be in the multi branched conditional library

Are you asking for them to be primitives? I guess anything in any library could be added as a primitive, but that'd be too many. We're going to try to work out a policy on library vs. primitive soonish.

The reason I say this is that it has an image as a help message instead of a pre set one with a comment

Oh right. Once upon a time, BYOB had just one library, called Tools. It took the form of a sprite, which had the advantage that its scripting area had examples of using each of the tool blocks. You could import that sprite and then delete it, and the blocks would remain. And I made help screens for all the Tool blocks. I'm trying to remember how I implemented CATCH and THROW in BYOB, because we didn't have first class continuations back then.

It's not clear that it'd be worthwhile for us to make CATCH and THROW primitives, for several reasons.

  1. Because CATCH and THROW aren't looping constructs, their implementation in Snap! doesn't really take any time.

  2. We don't have many practical examples of using continuations, so it's pedagogically valuable to preserve the implementation of CATCH and THROW using a continuation.

  3. Because the Control palette is already so huge, adding a new Control primitive costs more than adding, say, a Lists primitive. (It's a shame that clones, scenes, and metaprogramming each added half a dozen new Control blocks, but they each provide a capability not otherwise available.)

Well maybe it’s time to consider moving some of the control blocks to data? The meta programming blocks would be better as blocks in the “other” category as they aren’t exactly control blocks, well technically every block is a “control” block if they change something about the program.
And adding a “<I am [clicked v]>” operation would be beneficial to put them into the “when <>” hat block, and also be able to use them elsewhere.
And as I said previously with the removal of the continuation blocks that also frees up 2 more blocks.

While I do agree with the logic for continuations, they are going to be replaced in the next update requiring the block to either be reworked, or keep the obsolete/deprecated blocks there

They would also stay in the “multi branched conditonal” library if you want to see the definition so all that would need to be changed is the text in the help menu to be “they are used to invent control structures such as the CATCH and THROW blocks in the “multi branded conditional” library”

Oh, no, it'd be silly for us not to use the primitive if there were one.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.