Introduction
Recently I've been playing with custom blocks having at least one C-shape command among its inputs. What I've experienced is that using such C-shaped custom block makes for rather clunky editing.
Description of the issue
When a variable or a reporter is dragged anywhere near the C-shape a semi-transparent white rectangular veil appears, covering the C-shape and its contents; if one accidentally releases the variable or reporter block - even if only for a fraction of a second - it settles into the C-shape and causes its original contents to be ejected, which may be many lines of code. (I don't know how to shoot all this in Snap!, but I'm sure others will recognize what I've described).
It even applies to "official" library blocks, like (from "List utilities").
A solution exists! (or so I suppose) Snap! primitives with C-shape commands, such as: , , and
... won't be associated with this kind of havoc. So I guess it must be solvable.
Proposal
My proposal is that the "editing behavior" (for lack of a better word) of custom blocks with C-shape commands as inputs will be aligned with that of their cousins amongst Snap! primitives.
I may not understand what you mean. I wasn't saying no variables etc. may be substituted into slots of blocks contained inside the C-shape. All I've proposed is to do away with custom blocks behaving differently, while one is editing, from otherwise similar primitive blocks. Basically I'm asking for to behave just like .
i agree with this, in any of the primitive blocks youd use the RUN block, not drop it in the C. dropping a variable in the C is confusing because it's not very clear from the visuals that you can do it or what it will actually do.
i think most people's first experience with this is doing it by accident, which i think says a lot
Yes! This has definitely been a significant annoyance when creating large projects with custom blocks.
Personally, my solution to this problem would be to add an option in the input settings menu, similar to read-only, that would make it so nothing could overwrite what is inside the block input if something is already in it.
Being able to drop reporters - specifically variable getters - into custom command blocks' c-slots is an important pedagogical design to foster the understanding of "procedure as data", one of the truly powerful ideas in computing. Consider this recursive definition of while:
That's what we mean when we talk about "Beauty and Joy of Computing"!
[edit: ] I realize most of you aren't teaching / learning this in your CS classes. But that's what we made Snap! for, and that's totally what we believe kids have a right to be taught.
OK, now I understand the clunky editing of C-shape custom blocks is a direct consequence of a deliberate design decision, itself based on Snap’s educational character. That I hadn’t expected, but it makes sense now, thank you for explaining! (perhaps @d4s_over_dt4 tried to convey the same principle in post #2). So I’ll gladly rest my case (thx for the votes, people).
BTW the recursive WHILE block is a true brain teaser; it really only works the way you wrote it, with “test” being a predicate (not a Boolean), “test” being CALL-ed, and the WHILE tail recursion being an independent block (not RUN). Makes me wonder how many BJoC-students do grasp it .
i think the main issue is that variables can be dropped in even when the C already has code in it. in most other cases, dropping a variable into a filled slot doesn't work (at least when other slots are around it), and it seems odd that the least used case would be the easiest to do.
I don't think this is true; when you drag an expression over any filled slot you get a halo around the current expression and if you let go, the new expression replaces the old one. (But the old one doesn't just disappear; it stays in the scripting area, not attached to anything.) So I'm surprised that y'all are surprised that this is how it works even if it's a C-slot.
The fact that you can't put variables in the C-slot of (some) primitives is a misfeature, inherited from Scratch.
if you stack many reporters (such as operators), it's often impossible to replace any specific filled slot, i think there's a priority system.
i know there's a halo around the C, but i don't lock my mouse in place, check the halo, then release the mouse button. it would take years to make projects at that rate. the issue is that misdrops happen, and when they do it's easy to lose track of where things were, especially because it's now difficult to find where the C slot is, the popped out script is almost certainly overlapping other scripts, and after dealing with that you've probably lost track of where you were in the code in the beginning
I hadda look that up; I knew the word existed but had forgotten what it meant. It's an unintended behavior that turns out useful. But the thing about C slots of primitives isn't unintended; it's just wrong.
My statement was actually meant as a pun on INABIAF - I wasn’t even aware of misbug being a known (tongue-in-cheek) expression. Nonetheless, it was at least half-serious.
I fully understand Snap! developers sometimes choosing to prioritize pedagogical objectives over ease of use. However, if application of common (primitive) constructions such as FOR, REPEAT / WHILE and IF ...ELSE is, deliberately, going to be made more difficult out of principle, IMO the baby is being thrown out with the bathwater … students may be annoyed instead of encouraged to further explore Snap!’s many instructive features.
Although of course I'm familiar with the underlying sentence, this is the first time I've seen it acronymized. You learn something every day. (Strictly speaking it should be INBIF, but I get that that'd be less funny.)
It's not the case that we always put principle over convenience. Maybe the biggest counterexample is sprite inheritance: In principle, every attribute of the parent sprite should be shared with its clones, not copied, when the clone is created. But in fact some attributes are shared and others are copied, based entirely on how people ordinarily use each attribute. That sort of bothers me, but Jens talked me into it by citing the example of
which people use in a gazillion projects.
Even when it comes to dropping expressions into slots, we pay attention to convenience. Back a million years ago, in BYOB, if you had overlapping scripts (overlapping in their actual placement in the scripting area) and dropped something, it filled the topmost slot, iirc, which was a simple rule, but I convinced Jens that it should prefer empty slots even if the topmost one is filled. I'm probably misremembering the details, but the point is, we've tried to make it easy to use.
But yeah, in this case, you want to make it impossible to do something uncommon, so that's a big ask.
(from "List utilities").
(or so I suppose)
, 
, and 
.