That's because they use two totaly[sic] different code bases.
Ok.
We are done with custom hats, but what about custom caps?
Custom caps, or will you add a generic cap block?
[scratchblocks]
@[bh], pick one. :: events cap
{@[bh], pick one. :: control} :: events cap
[/scratchblocks]
or even,
[scratchblocks]
block { :: events} slots! :: control
[/scratchblocks]
what would be the purpose of a generic cap block
when you can just make a custom block that does the same thing
[scratchblocks]
Comment [Lets say you have a block that cuts a script in half,] :: grey
Comment [And one that continues the script.] :: grey
Comment [You cant make a block to do that because] :: grey
Comment [You can add more blocks after it.] :: grey
ask [Question] and wait
cut :: custom
Comment [see?] :: grey
//A generic cap would be of use.
ask [Question] and wait
{cut :: custom} :: control cap
when flag clicked
continue {
say (answer)
} :: custom
[/scratchblocks]
You could just have a custom block call [scratchblocks]
stop [this script v]
[/scratchblocks]
But you can still add blocks after it
but the blocks after it wont run
if you can name several good and practical reasons this would be useful, id vote for cap blocks.
[scratchblocks]
if <> report [] else [] :: control cap
Obsolete! :: cap
stop project :: control cap
<is ({cap :: cap} input names: ((1 :: variables) :: variables)::grey ring) a [cap v] ? :: operators
delete sprite :: control cap
{cap :: cap} :: control hat
stop [script v]
[/scratchblocks]
This might possibly come in 10.0
[scratchblocks]
delete puzzle, and unhide blocks :: + control cap
[/scratchblocks]
Neither; I don't think cap blocks (which is a very strange name, btw, since a cap is a kind of hat) are especially important. I'd rather work on hygienic macros.
Does every feature have to have a "fail safe" to avoid someone who doesn't use it for its intended purpose?
Your phrasing is pretending you to be a developer of snap
all of these examples you can already do in snap just as easily without cap blocks
and what's the purpose of the Obsolete! block?
oh you can already delete sprites too
Wow it’s chaotic here.
yea theres a debate on whether or not cap blocks are actually useful
The purpose of cap blocks isn't to increase programming power; it's entirely pedagogic: It tells the user that this block they're looking at expects to be the end of the script. So I don't see a huge benefit to building a cap block in code you're writing for yourself. I can see it if you're writing a big library like SciSnap that will be used by other people.
So I think examples of things that could be done with a cap block kind of miss the point. Maybe you could look through existing libraries and find things that would be more understandable if the library could have cap blocks.
By the way, STOP THIS SCRIPT is a little too aggressive as an implementation of the semantics of a cap; if the cap block is used in the definition of a custom block, it just stops that custom block, not the whole toplevel script. You want STOP THIS BLOCK, but you want to evaluate that in the context of the caller of the cap block, which you can now (in 9.0) do with metaprogramming:
if <> report [] else [] can easily be replaced with report (if <> then [] else []).
Yeah yeah, if you use it in the toplevel script, of course it stops that script. But the point is that if you use it inside a custom block, it still stops the toplevel script, not just this custom block call.