Note that the purpose of this topic is NOT to ask for support (we've had plenty of topics like that already - see below). It's to ask for IDEAS how to make global custom blocks work in an intuitive way, to find alternative ways to do it that will work around some of the issues I raise!
What I'm asking is this… Can YOU think up a better way?

Contents

• Introduction

• Scratch Team support

• So what's the problem…?

• Different ways to do it

• Issues & questions (in later posts)

OK, so after reading all of those sections – especially the different ways to do it and their respective posts (of course, I assume you read every word several times, didn't you…? yeah…? right…?) – I'd be curious to know if you have any ideas how to do it better, or how to overcome some of the problems/questions raised.

It'd be really great if some bright spark here could come up with some way to make global custom blocks work that none of us old fogeys have actually yet considered…



Introduction

We have global variables, which are accessible from all sprites (and Stage), so why not also allow the option to have custom blocks which can be accessed by any sprite (and Stage)?

This is a very popular suggestion which comes up regularly in the forums - here are some examples:
https://scratch.mit.edu/discuss/topic/260
https://scratch.mit.edu/discuss/topic/603
https://scratch.mit.edu/discuss/topic/3748
https://scratch.mit.edu/discuss/topic/6828
https://scratch.mit.edu/discuss/topic/12015
https://scratch.mit.edu/discuss/topic/20077
https://scratch.mit.edu/discuss/topic/37933
https://scratch.mit.edu/discuss/topic/48076
https://scratch.mit.edu/discuss/topic/50278
https://scratch.mit.edu/discuss/topic/58288
https://scratch.mit.edu/discuss/topic/105880
https://scratch.mit.edu/discuss/topic/126462
https://scratch.mit.edu/discuss/topic/130460

Of course, it gains a great deal of support (and why wouldn't it!) - presumably in the hope that the Scratch Team might take notice and so add such a feature.

But the purpose of this post is NOT to *suggest* the idea of global custom blocks (I suspect that might just've been done already, once or twice… ;P) It's to raise the issues and problems with various ways of doing it, in the hope that someone here can come up with something better!




Scratch Team support

The reality is that the Scratch Team had certainly considered this long before any of us - in fact while Scratch 2.0 was being developed (before we had even heard of it!)

So, did they not want it? Did they reject it?

No!

Here's (part of) a quote from one of the Scratch Team members:

The Scratch editor design team discussed this extensively when planning for Scratch 2.0. We all agreed that global procedures would be great to have and an important concept, but also recognized the challenges of adding it in a seamless way.

See here for the full context in which above appears: https://github.com/LLK/scratch-flash/issues/782
(BTW, it's actually well worth reading through that discussion if you want to think more about this…)




So what's the problem…?

Since it's clear that the ST would like to see this feature, and have known that for a long time, there must be a reason why it's not in Scratch even now.

The reason is that there are several subtleties which are not that obvious until you actually try to consider *how* to implement this feature.

What I will do below is outline a few possible ways to implement this feature, and then, in future posts, cover some of the problems that crop up with each.




Different ways to do it

I've included four of the major ways to implement this ‘global custom blocks’ feature - see the linked posts for more detailed thoughts about how they might actually work, along with some of the issues:

• Allow (the option for) custom blocks on the Stage to be accessible by all sprites (similar to global variables) – read more here…

• A new checkbox in the “New/Edit Block” window which, when checked, allows global access from all sprites (and Stage), no matter where that custom block is located – read more here…

• A new checkbox in the “New/Edit Block” window which, when checked, places a copy of that custom block definition in all (selected?) sprites (and stage?) – read more here…

• Provide a separate editing area for global custom blocks (which is a bit like how it works in Snap! / BYOB) – read more here…

Issues & questions

In the following posts I will go through each suggestion above, and list some of the issues and questions that arise when trying to implement it. And, yes, sorry, but this does get a bit technical at times…

First suggestion:

Allow (the option for) custom blocks on the Stage to be accessible by all sprites…

This idea is probably the most obvious, since it is so similar to the way that global variables work on the Stage.

However, here are some points to consider:

• There are a number of important blocks which are not available (directly) from the Stage, because they don't apply to the stage. For example, it has no motion blocks, since it can't move; there are various sensor blocks missing, such as the touching blocks and ‘distance to’; there are no pen blocks (except ‘clear’); many of the ‘Looks’ blocks are missing (e.g. say/think/show/hide/size); etc., etc…

• Would global custom block scripts have to use only global variables? Note that if only global vars are ‘allowed’, this would make it hard to use global custom blocks ‘concurrently’ from different sprites, since any time one of them changes a global var, it'll change for the others too - you can't use the same ‘counter’ type var from two sprites at the same time… (BTW, you really don't want to see the horrible mess that results if you try to use a pre-existing sprite-only variable in the Stage…)

• How does costume-switching work? (This is also a more general consideration for any implementation of global custom blocks - but I guess you'd have to either avoid it, or make sure you named/numbered the costumes consistently across sprites that use the global custom block…)

Second suggestion:

A checkbox in the “New/Edit Block” window which, when checked, allows global access…

This is also a fairly obvious idea – and it seems pretty intuitive at first…

However, here are some thoughts:

• When a global custom block definition in a sprite comes across a sprite-only variable, should it use it as if it belongs to the sprite which ‘hosts’ the custom block (in which case it has the same problem as the previous implementation in the Stage, concerning global vars), or should it treat them as local to the sprite/clone that's running that custom block (in which case, do you have to create that var in the hosting sprite first…?)

• There are various similar ambiguities over the use of various blocks (e.g. looks, etc.) - presumably, you'd really want a looks block in the global custom block script to affect the sprite/clone that's actually running the custom block, rather than the sprite that's ‘hosting’ the script… But that means, for example, a costume name/number would reference into the costume list for the sprite that's running the script, rather than the sprite that's hosting it - seems potentially very confusing, doesn't it…?

Third suggestion:

A new checkbox in the “New/Edit Block” window which, when checked, places a copy… in all… (selected?) sprites…

This acts rather like simply copying a custom block script from sprite to sprite, but with extra features that keep the scripts ‘linked’.

One advantage this has is that it overcomes some of the questions and ambiguities about who ‘owns’ the custom block script, and the variables and looks blocks within it, etc., since it exists in ALL (selected?) sprites (and Stage?)

However, it also ought to have the following in order for it work reasonably well:

• Any change to a shared custom block script (in any sprite which has it) must be reflected in ALL other sprites that also share it - we don't want to have to go into all the sprites that share it, and edit its script in each. But could it also be a bit confusing to have it change in different sprites like this…?

• All sprites which share the custom block script should, ideally, already ‘own’ any sprite-only vars used in the script (this will kinda happen anyway - as soon as the sprite comes across a var it doesn't already know about, Scratch will create it sprite-local) - BUT see below for Stage issue…

Here are some other questions:

• Is it perhaps a bit confusing to have a custom block script suddenly appear in all sprites when you check that box? (I can imagine someone doing it by accident - and then this lead to the unchecking question below…)

• What happens if you already have a custom block script with the same definition in another sprite where you want to share it? Does it create a second version of it in there (thus causing interference)? (Though there are already ways to create two versions of a custom block script in one sprite, and it does cause problems…)
  

• What happens if you uncheck the ‘shared’ checkbox? Does the custom block script go back to only its ‘original’ sprite? Does it stay in all of them, but now can be edited separately in each sprite? If the latter, that seems potentially confusing (and a pain to clear up if you checked that box by accident…)
  

Fourth suggestion:

Provide a separate editing area for global custom blocks…

This would act a little like it's a ‘second Stage’ (maybe even by having something that looks a bit like an extra sprite widget just below where the Stage widget is located?), but it would provide all the blocks that are missing from the Stage (as mentioned in first suggestion), pretty much as if it's a normal sprite.

Here's a quote from a ST member about this:

-
…a solution would be a separate block definition interface, as in SNAP (BYOB). However, a priority has been placed on making the definitions tinkerable and easy to try out, so that meant keeping them in the existing script interface, which means they're local not global.

…If we had a separate block definition area that would add complexity to the Scratch interface and model (including when reading others' projects), which is not ideal.

There are also several questions about how certain things might work:

• Presumably, all global variables would be available in the Data pane when in the new editing area, but would sprite-only vars have to be dragged from the relevant sprite and dropped into it?

• Conversely, it could maybe show ALL possible vars in the Data pane - but you'd have no way to know which belonged to which sprite, unless it shows every var from every sprite separated out by sprite - in which case there could be many unnecessary repeats. (OTOH, if a var doesn't exist already in a sprite [or stage] when a sprite uses it, then it gets created sprite-local, so it maybe doesn't matter which sprite it belongs to…?)

I also think this a rather large change to how things currently work, and I'm not sure it could be done in a way that transitions cleanly from the current way the Stage works, and without causing quite some confusion…

I actually read through everything…

Phew.

I'm gonna put it short: S. U. P. P. O. R. T.

What's there not to like

Support for every idea.
There should be something like private functions (only accesible to one sprite) and public functions (accesible to every sprite)

MathlyCat wrote:

I actually read through everything…

Phew.

I'm gonna put it short: S. U. P. P. O. R. T.

What's there not to like

What's not to like are the issues & questions I raised with the implementations.

But well done for reading it all! And thanks for the ‘support’ - though that's not really what I'm looking for.
(I mean, I fully support the *concept* of global custom blocks, of course - as does the ST - but I don't particularly like any of the ways I've suggested.)

I've added a little extra text in a couple of places to try to make that clearer…

This is a little messy, and unforunately an extension of the 4th one, but I think it solves all the issues in a mature manner (although raising more!):

Employ prototypical inheritance patterns. Next to Stage (on top of it?), there is Sprite. Anything here is automatically everywhere but the stage. This could include block definitinos that are not cleanly global, but also a wealth of other possibilities, like:

when this sprite clicked
say (join (join (x position) [, ]) (y position))

Now you have a magical new feature where you can click anything to find its position, which could be useful for debugging or something.

I don't know. Maybe it'll confuse new scratchers too much. But it seems like if someone could make a neater version of this metaphor, it would solve this problem (and make a lot of other awesome features!) with relative ease. (This would be fairly trivial to implement compared to something like linked definitions.)

Thoughts (=criticisms)?
~Alyssa

DadOfMrLog @ First suggestion wrote:

(BTW, you really don't want to see the horrible mess that results if you try to use a pre-existing sprite-only variable in the Stage…)

I didn't before, but now I do!

bobbybee wrote:

This is a little messy, and unforunately an extension of the 4th one, but I think it solves all the issues in a mature manner (although raising more!)

I kind of like this idea, but having the sprite called “Sprite” or “Prototype” sounds really confusing (what sprite? what's a prototype?), so perhaps instead name it “All Sprites”?

I think option 4 (global scripts section) is the best.
For the variables, I was thinking of something like this:

global variables: just treat them as normal global variables. They are the same in every sprite.

private variables: This needs to be a bit different. I suggest that you can only use the private variables that are specifically made accessible in the global scripts section (so the variables tab isn't cluttered with all variables of the entire project).To do that, you have a checkbox to ‘make this variable accessible in global scripts’, which you can modify at any time. If checked, it will make this variable in every sprite, and it can be modified within the global scripts. This private variable can have a different value for every sprite, and the value of the sprite which runs the custom block will be used. You can also create the variable inside the global scripts section. If you do that, you have the option to make the variable only show up inside the global scripts section, but it would work exactly the same way. This can be helpful if you use a lot of variables that you only need inside the global scripts, and would clutter up the variable tabs in your other sprites.

Also the global and private variables should be split up in two sections within the variables tab (just for making it a bit more organized).

To recognize a global custom block, there should be some kind of ‘global’ icon at the start of the text on the block (just like cloud variables have a ‘cloud’ icon). They should also be put under a new ‘global custom blocks’ section within the custom blocks tab.
The right click -> define tooltip would also redirect to the global scripts area.

Thoughts?

I think the global custom blocks should be literately “for all sprites,” not including the Stage (the Stage should be able to have its own local variables) where the block definition is placed in all the sprites and linked together like #3 (and variables used will be automatically created in each of the sprites). When “unsharing” the custom blocks, you have the option to unlink the blocks, meaning that the definition stays, but updating one of them it doesn't update in other sprites, or delete the block definition from all other sprites (no variables created in this process is deleted) unless the block happens to be used in one of the other sprites.

Having two custom blocks with the same name will continue to glitch.

Sharing a custom block would first check if a switch costume block is used, and if there is, then it would cancel the process.

TBH, I have to admit that I'm not much of a fan of the Stage being treated as ‘global’. I think I'd prefer to see it treated pretty much the same as a normal sprite (except it doesn't move, etc.), with it's own local vars, and then have a replacement ‘global’ or ‘common’ editing pane (shown as another square widget below the stage's one) that would house global vars and global custom block definitions.

It could also have some other ‘global’ features similar to bobbybee's suggestion above.

Note that, as I said about the fourth suggestion above, it would also need some kind of access to any sprite's (or clone's) local vars if it's going to use them. - I think this is probably the weirdest issue with this idea.

Unfortunately, all of this is rather a big change, and I find it hard to see how it might be done in a way that's also backward-compatible with current projects AND without causing lots of confusion…

Time to give this a bump!

(Thanks to those who have contributed ideas above - it's great to see some thought about how the variables issue might work…)

Well, I like the checkbox idea where there's a “global/for this sprite only” box. I don't see any reason to copy the script around, though, so let's do this:

When checking a special checkbox, add the block to the More Blocks palette in every sprite, but don't copy the script anywhere - leave it where it is. (Possibly divide the local and global blocks via a small horizontal line like how 1.4 used to do it. (Why don't variables do that anymore?)) This allows people to organize their blocks wherever they see fit, and if people use a lot of custom blocks they can organize them into a “block library” sprite. (which they can then share and add to their backpack! )

This of course leads to a little problem where it's possible to be using a block, and then forget what sprite the definition is in. It also seems to shatter Scratch's concept that scripts always belong to a sprite and always execute in that sprite's context, and nowhere else. So… maybe not.

You're doing a noble job bringing this topic into limelight. I cannot fully express my frustration due to the lack of accessibility options in Scratch. In fact, right now I'm working on a few secret projects that could really use global procedures and a few other important missing features. I realize the need for global procedures is mutual to the need for script-local variables - is not the root problem of global procedures because of the way variables work?

If we can solve the variable scope dilemma, we will ascertain global procedures.

What is the variable scope dilemma? That you can only have two kinds of variables: accessible to everything and accessible only to the sprite or clone. Among the sprite's scope, there is no baser level for variables. Therefore, “sprite only” variables are still “global” to the scripts. That means all variables are technically global, irrespective of their accessibility. This spells deep trouble for good programming.

Furthermore, garbage collection is severely limited in Scratch. The most you can do in a program is delete items in a list or delete a clone (which removes its copies of variables). Beyond that, you're stuck with using the same variables for all your scripts. Which really sucks when you want a script library to be “clean” of any distracting variables and lists.

The reason why I'm pointing this out is because the whole problem with making global procedures is determining ownership: whatever owns the variables owns the script. You can't make a global procedure use variables that are local to another sprite - yuck! Although you could use global variables for everything, that just makes the variable category absurdly messy and still would not solve the entire problem (e.g. recursion calls that require a new set of variables).

So now we have aim of what we need - script-local variables. If you call a block in sprite B from sprite A, the script utilizes its own variables for the work. Any action blocks like move () steps will be reflected in the calling sprite.

One thing is still missing: how to pass values back to sprites/stage. Obviously, at this point you could only use script-only variables and not get anything out of it. This leads us to another significant problem: returning values in Scratch.

Currently, the only way you can really return a value is either with a global variable or list. This makes it especially tedious when you have a complex recursion call that needs several returned values. I'm sure we can implement a similar “return” block like in Snap! and yada yada yada you get the idea I dont want to type this anymore skafjioiesshdgn9asdofe…….

tl;dr
script-local variables + return values = global procedures solved

ADDENDUM
Alternatively, we could just make this really simple: your suggestion for a checkbox to make a custom block global, and when called will act as if it is owned by the calling sprite/stage (the necessary variables will be made and actions will take place in the calling sprite/stage).

Zro716 wrote:

script-local variables + return values = global procedures solved

Yup, that's exactly the thoughts I've been having.

The main issue I see is the confusion about how such variables work – I can well imagine that Scratchers seeing the same-named variable in the same script area (but in different scripts) will struggle to understand why they are not the same thing.

I've seen similar confusion on the odd occasion over custom block params having the same name (but in different scripts), and yet it's much more obvious in that case because we have a clear indication that it ‘belongs’ to that custom block ('cos it's right there in its definition).

I suspect that may be (at least one reason) why the ST haven't implemented any kind script-local vars before now…?

DadOfMrLog wrote:

Zro716 wrote:

script-local variables + return values = global procedures solved

Yup, that's exactly the thoughts I've been having.

The main issue I see is the confusion about how such variables work – I can well imagine that Scratchers seeing the same-named variable in the same script area (but in different scripts) will struggle to understand why they are not the same thing.

I've seen similar confusion on the odd occasion over custom block params having the same name (but in different scripts), and yet it's much more obvious in that case because we have a clear indication that it ‘belongs’ to that custom block ('cos it's right there in its definition).

I suspect that may be (at least one reason) why the ST haven't implemented any kind script-local vars before now…?

How difficult would it be to understand if they put next to the blockspec a Snap! style “click to expand” list of creatable variables?

The second one seems like the best option to me.

DadOfMrLog wrote:

However, here are some thoughts:

• When a global custom block definition in a sprite comes across a sprite-only variable, should it use it as if it belongs to the sprite which ‘hosts’ the custom block (in which case it has the same problem as the previous implementation in the Stage, concerning global vars), or should it treat them as local to the sprite/clone that's running that custom block (in which case, do you have to create that var in the hosting sprite first…?)

• There are various similar ambiguities over the use of various blocks (e.g. looks, etc.) - presumably, you'd really want a looks block in the global custom block script to affect the sprite/clone that's actually running the custom block, rather than the sprite that's ‘hosting’ the script… But that seems potentially confusing, doesn't it…?

• I think the best thing to do in that first case would just be to skip over stacks involving or containing local variables, that is, if they don't also exist in the sprite calling the procedure. Alternatively, you could set the variable sprite-side whenever any sprite runs that part of the proc, but isn't the point of local vars explicitly to prevent this from happening?
  
• If a costume, sound, etc. is referred to and the sprite running the custom block doesn't have one by that name, then again, I feel the best thing would be to ignore it. And if I understand you correctly, for preventing looks and whatnot from updating in certain sprites, I have a simple solution. Because we would now have both local and global procs, you could just create a local custom block in the global definition containing the looks changes. When running the global block, sprites with the local procedure could refer to it and update accordingly, whereas those without it could just skip over and move to the next stack.
  

Bump.