I am really enjoying teaching beginners inheritance in Snap. Working with clones and inheritance separately makes inheritance less of a mental load when working on projects. This has proven to translate well into OOP (or at least OOP environments like Greenfoot without having to formally teach OOP concepts).
One hurdle students face is knowing what is being inherited. It is frustrating to realize you've been working on a child's script thinking you are working on the parent.
One idea would be to reduce the alpha on scripts (and maybe variables) that are inherited, that way there is feedback to the programmer when inheritance is removed.
If by "scripts" you mean scripts that are visible in the scripting area, then either all are inherited or none are. There's no deep intellectual reason for this; it's just a big simplification.
Temporary clones always share all scripts with their parents; since they have no scripting area of their own, those are the only scripts they can use. Permanent clones do not share scripts by default, but if you right-click on the scripting area, there is an "inherited" checkbox that causes the child's scripting area to be identical to its parent's. As with other inheritance links, this link is broken if you edit a script in the child. At that point, all scripts are copied from the parent to the child.
So what you're suggesting, really, is to ghost out the entire scripting area in a permanent child when the checkbox is checked. I don't think that's a bad idea; we'll see what Jens says.
Sprite-local custom blocks and variables are shared individually, and they are ghosted out in the child if shared.
Don't miss the opportunity to blow your students' minds by showing them OOP using lambda, SICP-style!
You nailed it on the scripting area. And I double-checked the local variable shading and you are right! Maybe that is where I got the idea.
Just brainstorming... could inherited variables, in a non-inherited scripting area, be shaded as well?
I'll be honest, I struggle with internalizing lambda-based OOP, in Snap! I think of them as closures which might be the problem. I need a good problem my students can immediately see the value of. Maybe when I'm getting into abstract data types. Time for some exploration!
inherited".