So I suggested an ‘as’ block in a different thread, and a bunch of people seem to like the idea. What it looks like:

as [Sprite2 v] {
move (10) steps
next costume
wait (3) secs
hide
} :: control

Essentially, what it does is executes the blocks inside from the context of a different sprite. So even if this example was placed in Sprite1, when executed, it would be Sprite2 that moved 10 steps, switched costumes, and hid after 3 seconds.

I'm not entirely sure what the uses of this block are, but I imagine something similar to OOP-type design could be done with them (i.e. injecting private variable values into other sprites?)

There are obvious issues with this block, the main ones being variable name resolution - that is, if two variables are named the same thing in both sprites, which one is accessed? I would say access the calling sprite's variables - that is, the variables that belong to the sprite that the script is placed in, but that is up for debate - and could make the block more confusing.

The other ambiguity issue is with "stop [other scripts in this sprite v]." The question is whether it should stop scripts in the calling sprite or in the target sprite. In this case, I actually believe that it might be better to stop scripts in the target sprite - but this would multiply issues, and it would break encapsulation (if anybody happens to care about that…)

So, what are your thoughts? Do you have any ideas on how this could be used, or how the issues with it could be worked out? Do you have a better name for it? Discuss!

I think this is a really cool idea, it is a lot faster than to broadcast a message and do the same thing.

Support. It would save a LOT of time when making projects.

bad name. it would confuse scratchers.

I suggest:

make [Sprite2 v] do {
move (10) steps
next costume
wait (3) secs
hide
} :: control

theonlygusti wrote:

bad name. it would confuse scratchers.

I suggest:

make [Sprite2 v] do {
move (10) steps
next costume
wait (3) secs
hide
} :: control

I was going to say the same.“as” makes it sound like it becomes the sprite.


I think this would be great if you can insert a variable into it. That way you can change what sprite it moved while playing it, and that is harder to do with broadcasts.

First of all, support.
Next, I think that if Sprite1 makes Sprite2 do something involving a variable called “i”, and both sprites have their own personal variable called “i”, then the script should use Sprite1's “i”, as this could help when both sprites need to individually use their own personal “i”s but Sprite2 needs to somehow access Sprite1's “i”.
Third, I think that “stop other scripts in sprite” should stop scripts running in Sprite2 besides that one. This would be extremely useful as a workaround to a “stop this sprite” block, and would also enable remote stopping of sprites.
Fourth,

powercon5 wrote:

I think this would be great if you can insert a variable into it. That way you can change what sprite it moved while playing it, and that is harder to do with broadcasts.

I think you are absolutely correct, @powercon5. That should be a feature.

theonlygusti wrote:

bad name. it would confuse scratchers.

I suggest:

make [Sprite2 v] do {
move (10) steps
next costume
wait (3) secs
hide
} :: control

I completely agree with you too, @theonlugusti. I actually suggested a slightly different change of name in the original thread that this was posted in:

do {
    move (10) steps
    next costume
    wait (3) secs
    hide
} as [Sprite2 v] :: control

but yours looks better and makes just as much grammatical sense.
That's the only thing I need to say right now. Happy Scratching!
EDIT: @theonlygusti, I suggest removing the “do” in “make sprite do”

Support.

sakafitrady wrote:

Support.

Hi there, could you please give more detail to your posts instead of simply saying one word?
The post you have made tells us nothing, so to make sure your post is actually beneficial, take the time to include reasoning, suggestions, evidence and so on. To make sure your replies are as constructive as possible, read this sticky.

Thanks for reading

Sigton

no support
sprite1:

broadcast [do v] and wait

sprite2:

when I receive [do v]
do stuff::grey

Another problem (not so much ambiguity as usability) is sprite-specific blocks, like the switch costume dropdown or local variables. Dropdowns could be fixed by changing the available options based on where the sprite is located, but local variables of the target sprite would have be dragged out as something else, then right-clicked to change them. Also, this would require sprite-only blocks like movement to be accessible in the stage.

How would custom blocks work? Would it use the blocks from the sprite executing the ‘as’ block, or the sprite that is being told what to do?

Also, I like Snap!'s wording for this block better:

tell [Sprite v] to  {
do ::custom
stuff ::custom
} ::control

Sigton wrote:

sakafitrady wrote:

Support.

Hi there, could you please give more detail to your posts instead of simply saying one word?
The post you have made tells us nothing, so to make sure your post is actually beneficial, take the time to include reasoning, suggestions, evidence and so on. To make sure your replies are as constructive as possible, read this sticky.

Thanks for reading

Sigton

Oh ok. I would like it because it would make games much more simpler.

BookOwl wrote:

Also, I like Snap!'s wording for this block better:

tell [Sprite v] to  {
do ::custom
stuff ::custom
} ::control

That's the best wording I've seen so far. The reason I like ‘as’ better than ‘do’ is because it flows naturally in terms of language - i.e. ‘as Sprite2, move 10 steps’ sounds better than ‘make Sprite2 do move 10 steps’. But 'tell [v] to' also works - ‘tell Sprite2 to move 10 steps’ is very very clear in what it does, and flow naturally.

BookOwl wrote:

How would custom blocks work? Would it use the blocks from the sprite executing the ‘as’ block, or the sprite that is being told what to do?

This, I think, is very similar to the local variables question - which there has been little discussion on. Personally, I think that it should probably be that the target sprite gets first priority in terms of name resolution, as that essentially allows for modularization. For example, let's look at a text engine:

//Inside the 'text' sprite:
define draw string (string) at (x), (y)
...

//Inside some other sprite:
when gf clicked
tell [text v] to {
draw string [Hello, world!] at (10), (-20)
} :: control

BUTP

kenny2scratch wrote:

theonlygusti wrote:

make [Sprite2 v] do {
move (10) steps
next costume
wait (3) secs
hide
} :: control

EDIT: @theonlygusti, I suggest removing the “do” in “make sprite do”

I know that when read with blocks inside, it doesn't make much sense, but imagine seeing a "make “ block in the scripts palette; that would be very ambiguous and definitely confusing. That's why I suggest ”make do"

This would be very useful and would be used in lots of games of mine
Support
EDIT:

I know that when read with blocks inside, it doesn't make much sense, but imagine seeing a “make “ block in the scripts palette; that would be very ambiguous and definitely confusing. That's why I suggest ”make do”

that makes sense but “make sprite do move 10 steps” does not make sense, that is why he said it should be make sprite, so it would be ‘make sprite move 10 steps’

I think that the block should access the target sprite's variables.

Three wording ideas so far:

as [Sprite1 v] {

}::control
make [Sprite1 v] do {

}::control
tell [Sprite1 v] to {

}::control

So far I like the first wording the most, but to make it clear to others I think the second wording is the best.

You were wondering two things about the functionality of the block. I believe anything done inside the block is done as if it was done in the sprite it targets, meaning every variable is referenced from the target sprites' variables, and this:

make [Sprite1 v] do {
stop [other scripts in this sprite v] ::stack
}::control

Will stop all other scripts in Sprite1.

That aside, I don't see what's wrong with using a broadcast.

Ok, the best wording is tell.

theonlygusti wrote:

Ok, the best wording is tell.

I agree. “Tell” is easier for younger users to understand than “make” or “force” is.