When [variable v] changes hat

joefarebrother

I suggest adding the following hat block:

when [var v] changes :: variables hat

(not sure whether to put it in the variables or control tab, I'll make the scratchblocks the variable colour for now)

It would do exactly what it says on the tin: it would run the script under it.

Why would this be useful?

Firstly, consider this: There are several things that scratch can set, but not get. Pen colour is one example. The common workaround is that every time you change the pen colour, you change a variable too, then use that variable elsewhere in the program. But what if you forget at some point? If you change the variable but not the pen colour, or vice versa, you would get inconsistent code. You could gust use a custom block, e.g:

define set pen colour to (colour)
set pen color to (colour)
set [pen colour v] to (colour)

but if you have to do this with a lot of variables it would just clutter up the more blocks section. And or global things, such as video transparency, you'd need this block in every sprite. Another workaround would be

forever
  set [old var v] to (var)
  wait until <not <(old var) = (var)>>
  ...
end

but this requires another variable, and would be less efficient because it would check the variable every frame rather than just when it changes.

Enter, my suggestion. In this case, you'd just have to do

when [pen colour v] changes :: variables hat
set pen color to (pen colour)

You could also keep track of the number of times and how often a variable was changed, which would be useful for debugging and optimisation.

Another possible use would be a system for intersprite communication, as an alternative to broadcasts, which carry additional info. If in one sprite you changed a variable called, say message, another sprite could detect that change and do something with it to respond to the message.

What I think it would be REALLY useful for though, and is what inspired the suggestion in the first place, is cloud variables. You could send messages via a cloud variable to another instance of the project, which would be able to detect this change and handle it specifically. For example, the cloud list engines that encode lists with numbers that can be stored in cloud variables would be able to check for updates this way rather than periodically decoding and encoding a few KB of data every few seconds.

when [☁ var v] changes :: variables hat
decode (☁ var) :: custom

The workaround of changing another variable obviously wouldn't work, so the only other workaround (that I know of) is to use wait until, which could be REALLY inefficient - it would have to keep on checking the server for an update.

Instead, with this hat, the server could just notify all instances of a project, via a websocket, when a cloud variable changes. If that's not how cloud variables are already implemented, it should be.

(secondary suggestion:

 when [list v] changes :: lists hat

would work the same way and have the same advantages. Although, this is actually possible to make a REAL workaround for (that doesn't require a new custom block for every variable you want to monitor) via the use of save file hacking)

Supporters:

theonlygusti
Abstract-
adespotist
jokebookservice1
iamunknown2

Non supporters:

pvz_pro
DaSpudLord
helloandgoodbye9
ChildCritic

Quotes from supporters:

theonlygusti wrote:
I think this will be useful, especially when programming in an event-driven driven way. It broadens Scratch's capabilities tremendously, and allows new programming paradigms to be explored by Scratchers.

theonlygusti wrote:
This would open up new programming paradigms to Scratchers, thus making the creation of event-driven projects easier (such as OS projects) yet also enabling (as joefarebrother pointed out in the OP) Scratchers to store the state of certain values not stored by Scratch. Doing so through variables also allows better management of projects and better internal organisation.

adespotist wrote:
This suggestion would be great for my projects! You could also do a (very hacky) loop workaround with this too.

iamunknown2 wrote:
The point of programming is to get the work done elegantly - not use a dozen of ugly workarounds that can mess up your program and require you to spend countless hours to debug.

Quotes from non supporters:

EVERYONE wrote:
Workarounds

Last edited by joefarebrother (April 28, 2016 22:35:36)

edward789121

2 wokarounds:

when green flag clicked
forever
    set [old var v] to (var)
    wait until <not <(var) = (old var)>>
    ...
end

and

define set var to [this]
set [var v] to (this)
broadcast [var changed v]

when I receive [var changed v]
...

joefarebrother

I mentioned the first workaround in the post, and why the hat would be better: the workaround requires another variable, and is less efficient. If you had to do it with a lot of variables, it would lead to a lot of repeated code and extra work. The second workaround isn't explicitly mentioned in the post, but it is a variant of the other workaround I mentioned, and has the same problems; If you have to do it with a lot of variables, it would clutter up the more blocks section, and you would have to remember to always use the custom block instead of the set variable block for variables you want to monitor, which again becomes inconvenient, especially if you don't monitor a variable at first, but then later decide you want to.

I don't think you read the post because I did mention workarounds.

And “It has a workaround” isn't a good reason for rejecting an idea: You might as well remove the whole custom block section. They can be worked around with broadcasts. Don't need any c blocks except repeat until (even “if” can be worked around:

set [done v] to (0)
repeat until <(done) = (1)>
  ...
  set [done v] to (1)
end

Only hat blocks you need are green flag and when I receive.

Don't need move () steps, that's just

go to x: ((x position) + ((steps) * ([sin v] of (direction)))) y: ((y position) + ((steps) * ([cos v] of (direction)))

Don't need wait () secs, that's just

reset timer
wait until <(timer) > (secs to wait for)>

…ect.

Just “It has a workaround” isn't a good reason to reject a suggestion.

Last edited by joefarebrother (April 27, 2016 22:40:21)

pvz_pro

no support, workaround is easy

joefarebrother

Did you READ my previous post?

The workarounds are much more inconvenient.

Last edited by joefarebrother (April 27, 2016 22:52:17)

DaSpudLord

No support. I don't see this being useful. And yes, I read the OP.

Sheep_maker

Extra variables and more work doesn't mean isn't a bad thing. That's coding in a nutshell, right?

theonlygusti

edward789121 wrote:

2 wokarounds:

when green flag clicked
forever
    set [old var v] to (var)
    wait until <not <(var) = (old var)>>
    ...
end

and

define set var to [this]
set [var v] to (this)
broadcast [var changed v]

when I receive [var changed v]
...

Neither of those are true workarounds. And anyway, they add a lot of overhead where it isn't necessary.

DaSpudLord wrote:
No support. I don't see this being useful.

I think this will be useful, especially when programming in an event-driven driven way. It broadens Scratch's capabilities tremendously, and allows new programming paradigms to be explored by Scratchers.

I don't see the

change [whirl v] effect by (10)

Being overly useful either, yet it exists.

theonlygusti

If it wasn't clear enough, I

Support!

This would open up new programming paradigms to Scratchers, thus making the creation of event-driven projects easier (such as OS projects) yet also enabling (as joefarebrother pointed out in the OP) Scratchers to store the state of certain values not stored by Scratch. Doing so through variables also allows better management of projects and better internal organisation.

joefarebrother

Sheep_maker wrote:
Extra variables and more work doesn't mean isn't a bad thing. That's coding in a nutshell, right?

Code repetition is a problem though. Having similar but slightly different code in 20 different places is a sign something could be more efficient. I'd agree with this specific workaround, *if* scratch had a “temporary variables” block to create a variable for only the script it's in. But in general, a lot of programming is about getting things done in the simplest way possible. There are lots of libraries dedicated to preventing code repetition. But there are only 2 languages I know of (scheme and common lisp, both derivatives of a single language, lisp) that fully solve the problem with a feature called macros.

Last edited by joefarebrother (April 28, 2016 07:06:28)

joefarebrother

theonlygusti wrote:
If it wasn't clear enough, I

Support!

This would open up new programming paradigms to Scratchers, thus making the creation of event-driven projects easier (such as OS projects) yet also enabling (as joefarebrother pointed out in the OP) Scratchers to store the state of certain values not stored by Scratch. Doing so through variables also allows better management of projects and better internal organisation.

Thanks! I'll quote this on the OP when I get back to a computer.

helloandgoodbye9

joefarebrother wrote:
I mentioned the first workaround in the post, and why the hat would be better: the workaround requires another variable, and is less efficient. If you had to do it with a lot of variables, it would lead to a lot of repeated code and extra work. The second workaround isn't explicitly mentioned in the post, but it is a variant of the other workaround I mentioned, and has the same problems; If you have to do it with a lot of variables, it would clutter up the more blocks section, and you would have to remember to always use the custom block instead of the set variable block for variables you want to monitor, which again becomes inconvenient, especially if you don't monitor a variable at first, but then later decide you want to.

I don't think you read the post because I did mention workarounds.

And “It has a workaround” isn't a good reason for rejecting an idea: You might as well remove the whole custom block section. They can be worked around with broadcasts. Don't need any c blocks except repeat until (even “if” can be worked around:
set [done v] to (0)
repeat until <(done) = (1)>
  ...
  set [done v] to (1)
end
Only hat blocks you need are green flag and when I receive.

Don't need move () steps, that's just
go to x: ((x position) + ((steps) * ([sin v] of (direction)))) y: ((y position) + ((steps) * ([cos v] of (direction)))
Don't need wait () secs, that's just
reset timer
wait until <(timer) > (secs to wait for)>
…ect.

Just “It has a workaround” isn't a good reason to reject a suggestion.

YEs, it is a good reason. There is no workaround to no screen refresh and other advanced features, so we still have custom blocks.
Also, the ones you wrote are complicated ones; this one is easy.
Please get your facts right before telling people to read the OP.

joefarebrother wrote:
Did you READ my previous post?

The workarounds are much more inconvenient.

*Gasps* Oh no I need a custom block!

joefarebrother

helloandgoodbye9 wrote:
*Gasps* Oh no I need a custom block!

More like “Oh no I need 20 difference custom blocks that all do practically the sane thing but with different variables, and every time I want to change a variable I need to make sure to use the right custom block instead if the set block that's designed for changing variables, also these custom blocks don't work for cloud variables”

ChildCritic

I do not mind at all using the workaround referenced in your post.
I grade workarounds more on complexity, than how easily it is constructed.
That workaround passes both.
No support.

joefarebrother

change [ v] by (0)

has an easy workaround, but I bet you still use that.

If you had to use a workaround a lot, the ratio of boilerplate code to code that actually does stuff adds up.

Abstract-

theonlygusti wrote:
If it wasn't clear enough, I

Support!

This would open up new programming paradigms to Scratchers, thus making the creation of event-driven projects easier (such as OS projects) yet also enabling (as joefarebrother pointed out in the OP) Scratchers to store the state of certain values not stored by Scratch. Doing so through variables also allows better management of projects and better internal organisation.

DaSpudLord

joefarebrother wrote:
change [ v] by (0)
has an easy workaround, but I bet you still use that.

If you had to use a workaround a lot, the ratio of boilerplate code to code that actually does stuff adds up.

So how easy do you want us to make coding? Do you want us to make coding super easy to the point where there is literally no effort involved? How about we add a block that does this?

when gf clicked
make a platformer::control
also I want there to be enemies that shoot [fireballs v]::motion

We can't make coding too easy, now can we?

joefarebrother

DaSpudLord wrote:
joefarebrother wrote:
change [ v] by (0)
has an easy workaround, but I bet you still use that.

If you had to use a workaround a lot, the ratio of boilerplate code to code that actually does stuff adds up.
So how easy do you want us to make coding? Do you want us to make coding super easy to the point where there is literally no effort involved? How about we add a block that does this?
when gf clicked
make a platformer::control
also I want there to be enemies that shoot [fireballs v]::motion
We can't make coding too easy, now can we?

https://en.wikipedia.org/wiki/Straw_man_argument

I never said no effort.
What I meant was, the less time you have to spend worrying about writing boilerplate code, the more time you have to make actual program logic, such as making a platformer game where enemies shoot fireballs.

AwesomePerson238243

I love your signature i 8 sum pi is my favorite math joke

joefarebrother

AwesomePerson238243 wrote:
I love your signature i 8 sum pi is my favorite math joke

Off topic, but thanks! Refreshing to see some positivity I'm this thread

Discuss Scratch