Is it possible to share a block across multiple sprites? If not, this would be great for code reuse.

learnegy
Is it possible to share a block across multiple sprites? If not, this would be great for code reuse.

With one definition? no.
But you can easily copy the definition script into your backpack and paste it into other sprites.

Just duplicate the code and drag it into other sprites.

ka-doink4545o0
Just duplicate the code and drag it into other sprites.

I guess that would work although it seems contrary to the one of the primary concepts of function (code reuse and abstraction). Perhaps, the Scratch devs would consider an option to make blocks global, similar to the way it is done for variables – “available to only this sprite” or “available to all sprites”

We did consider this early on, but decided against it. One of the reasons (it was a long conversation) had to do with the possiblity of getting mixed up / confused as a result of blocks with similar names. So for simplicity's sake we decided to just make each block local - it will run whatever the block definition says it will run.

Of course, you can still copy that definition between sprites via the backpack. And if you need a bajillion of them, you can always use clone.

Lightnin
We did consider this early on, but decided against it. One of the reasons (it was a long conversation) had to do with the possiblity of getting mixed up / confused as a result of blocks with similar names. So for simplicity's sake we decided to just make each block local - it will run whatever the block definition says it will run.

Of course, you can still copy that definition between sprites via the backpack. And if you need a bajillion of them, you can always use clone.

And what if we want to go back and change the behaviour of the block after we copied it 20 times?

Lightnin
We did consider this early on, but decided against it. One of the reasons (it was a long conversation) had to do with the possibility of getting mixed up / confused as a result of blocks with similar names. So for simplicity's sake we decided to just make each block local - it will run whatever the block definition says it will run.

I agree; naming could definitely be an issue for new users; good decision by the Scratch team.

One interesting workaround/enhancement could be giving the stage the ability to set attributes for other sprites via the sensing palette. The stage already has the ability to get attributes of other sprites using the () of () sensing block. This would also benefit beginning programmers by introducing the concept of getting and setting attributes which is fundamental to OOP. These modifications would be visible on the stage only to avoid any confusion:

Here are a few options:

1) Adding a block to the Data Palette that combines the existing functionality of the () of () sensing block with the Set () to () block




2) Allow the existing () of () sensing block to snap into the Set () to () block. This would not require any additional real estate and could be introduced to beginners as an option with very little likelihood of them using it by mistake on their own. Here is an example:




3) Adding get and set options to the existing current () of () sensing block:

I like the first one, but as a sensing block for all sprites and the stage. This reduces the need for many broadcasts which are only broadcasted once for a simple task, and also, as you said, helps learn important OOP concepts. But how does this help share blocks across sprites?

Hardmath123
But how does this help share blocks across sprites?

I guess I was thinking out loud a bit. When thinking about the major use cases for sharing blocks, I found myself returning to the need for abstracting common functionality and making it reusable across multiple sprites. For example, enabling the stage to respond to broadcasted events by modifying properties of multiple sprites as opposed to having every sprite listening and responding individually.

<thinking_out_loud_again>

Here is a scenario combining a setter block (example 1 above) with a custom block function that is able to accept Sprites as a parameter. This would be very expressive syntax and a great way to use Scratch as an introduction to object oriented programming concepts. Especially for younger students to visually see that all “Sprites” share common set of properties that can be changed by the stage.





</thinking_out_loud_again>

Another idea would be for sprites to be able to access custom blocks in other sprites by changing the custom blocks to a format like this: thing.doWhatever (42). Without the period at the end, that is. If that's too ugly for new Scratchers to bear (I am now learning to expect and preemptively prevent this kind of annoying, overused argument from being used to ruin perfectly good ideas), then the portion of the block label denoting the sprite containing the definition should not show up unless the block is dragged to another sprite.

Edit: Oops, I only just realized how old this is. However, I feel I made a useful point, therefore my necroposting was justified.

Yeah, I don't get why you would create a block that was local in scope.

I mean, there are some applications there, but there are far more when it can be shared. My initial thought was to put the block in the stage. Maybe that's a way?

I agree with most of the other posters here, when using this as a teaching tool, not being able to share blocks across sprites means that common functions (run/jump/etc..) have to be copied and re-written. This defeats one of the purposes of having global functions. Maybe a global checkbox which would ensure there are no name conflicts (don't allow local names to conflict with global names defined or for folks to check global if more than one local exists?). I certainly agree that we don't need Scratch to expose students to masked namespaces for functions.

One of the options might be using a sprite for each important block or the series of blocks. Going back and force by sending messages and waiting for blocks to finish is kind of cumbersome but it does work. It also resolves the issue with doing updates.

If a sprite could assign one of its blocks to a global variable, the block would be available to other sprites without introducing namespace problems. You'd just need to a command to execute it. You'd also want to be able to pass a block or a variable containing a block as a block parameter, then, of course.

(jbrinz's dad, not jbrinz talking)

when green flag clicked
say [take the script and place it in the "backpack"

My browser / operating system: Windows 8.1, Chrome 39.0.2171.99, Flash 16.0 (release 0)]

I was considering use Scratch to tech my kids to do code - but this inability to share blocks across sprites / reuse is a complete showstopper: I wrote one silly game using Scratch, but hated that copy-paste coding. It is one of the worst habits coders can have and I would not encourage anyone to do it. Redundant code is just evil.

One idea to improve the situation is to create another type with Sprite, “Function” - above there was concern with naming and if Functions are in the same namespace than Sprites there is no such problem - the functions shall be pure and thus not have any internal state/data, that would let Sprites use them concurrently and independently. Sprite just call a Function output would only dependent on inputs. The input can be value or Sprite, but function shall not have access to Sprite internal variables (access to internal would bring tons of issues).

This discussion has maybe done several times, but its a real pity that Scratch has these issues (there are other as well, but this is the most annoying now :-) )

Agreed, this is a shame.

I agree it would be a nice feature to be able to share custom blocks between sprites, but on the other hand, I look on Scratch as an introductory language. There are quite a few limitations to Scratch and referring to those can be a great ‘selling point’ when trying to convince students that languages like Python or Ruby - which look a look harder/complex when compared to to the drag-n-drop of Scratch - have real benefits and advantages.

Having seen first hand the havoc caused by copy and paste programmers out there in the wild, I'm quite shocked that Scratch is teaching kids such terrible programming habits! From my experience people retain these programming habits there entire lives, it encourages lazy planning and ad-hoc incremental development, and people who can't work well in teams.

I recently worked on a Scratch project that required 50 copies of a method block using the backpack, even my 7 year old was telling me it was a bad idea, but I had to explain that its just the way that Scratch works. The thing is that by the time they start using blocks, they're starting to think in more advanced programming concepts anyway and its time to start teaching them proper planning and reuse. Otherwise the code becomes overly complex and too difficult to manage. Sure you could argue that they should graduate to Python, but it is just one of those problems with learning to code before your fingers can type …

Understand the name space issue, but there has to be a way around this. Why not number blocks like sprites for additional clarification ? You could access them from a list like costumes or sounds and reorder them based on how frequently they would get used. Or simply not allowing similar names to be used. I mean ultimately it should be flexible enough so that you can create custom reusable blocks that you could “load in” to a project or share with other users, after all that is the way real programmers use source control to work in teams.

Personally I think its much more important that kids understand such concepts rather than to let them run wild without fostering a philosophy of reusability …