I like the system of having local and global blocks. It's a great introduction to object-oriented programming without teaching it directly (I like that I can also teach the concept inheritance later in my intro course).
It would be great if there were a way to change a global variable or block into a local and the other way around. I know this would require a lot of work on the back-end (working with making blocks obsolete and such) and might make for a steeper learning curve for younger beginner programmers. Still, the benefit would be a more natural means of introducing encapsulation and scope.
If this were possible, it would make more sense to default to local variables and blocks. The local blocks could then be changed to global as needed. For my students, the default to global is a barrier for students making cleaner sprite code, which students are often too novice to think about ahead of time.
In my introductory high school course, the first project involves students making drawings using local sub-procedures (some prebuilt drawings to edit with the option to make their own). They work in teams, and each member creates different parts of the drawing. They then export their sprites to complete the final drawing. If you are wondering, the drawing is a "space-scape" with planets and stars and such.
I emphasize the need for students to use local blocks; otherwise, the importing of sprites becomes difficult. Students always miss or forget this, and it requires a manual refractor from global to local. A simple menu option to do this change would help in this case, and I imagine in most cases.
Yes, that's on everyone's wish list, but I gather it'd be quite difficult to implement, so don't hold your breath.
No, here I disagree. We're happy to have options for advanced users/students, but our defaults are set for the benefit of beginners, who don't know or care about scope. Anyway, a much more valuable thing for code cleanliness would be internal definitions, so a Block Editor could have more than one script in it, and the secondary ones would be visible only within the Block Editor's scope, and would have access to the outer block's local variables. Don't hold your breath for this, either, but I want it desperately.
Here you are pushing against one of the super big disagreements between me and Jens. For reasons I don't understand, and therefore won't try to explain, he gets mad every time I point out that whenever a user wants to save some blocks, we should actually save the transitive closure of their set of blocks: those blocks, and the blocks they call, and the blocks they call, etc. In your situation, there's no reason that couldn't include global blocks.
Yeah, whenever a design decision comes up someone suggests this. Jens hates adding settings because then the interpreter has to check those flags forever, slowing down Snap!.
This particular one might get past the efficiency hurdle because it would only slow down creating blocks and variables, rather than using them, so it doesn't matter so much.
But another objection to settings is that learners, especially beginners, can't just learn a rule and stick with it. Every project you open might have different rules. Almost always, it's better for us to pick the right answer according to our lights, and stick with it.
(This is why Richard Stallman invented Emacs. Everybody at the AI Lab customized their TECO settings, including the meanings of the control codes, and as a result nobody could ever type on someone else's terminal. So RMS went around and polled everyone about their favorite settings, and built those into Emacs as primitive. And then of course he included a Lisp interpreter so that people could customize it however they wanted, but the basic key bindings were good enough that mostly people left them alone.)
I don't think it makes sense to talk about internal definitions unless there's a definition (i.e., a Block Editor) for them to be internal to.
Umm, I think sprites just save the blocks that are "for this sprite only" i.e., sprite-local. Your initial post in this thread seemed to suggest that, too.