NetsBlox / Snap--Build-Your-Own-Blocks

a visual programming language inspired by Scratch
http://snap.berkeley.edu
GNU Affero General Public License v3.0
3 stars 6 forks source link

Sending motion blocks to another project should move the recipient sprite #906

Open brollb opened 4 years ago

brollb commented 4 years ago

It should be possible to send motion blocks to another project/role to provide behavior to a sprite in the recipient project. Currently, the motion blocks apply to the snapshot of the sprite from the original project included in the serialized form. (That is, it is basically a no-op.)

This is actually part of a much bigger question. In Snap!, the "receiver" of an anonymous function (the sprite that the given blocks affect) is the sprite who originally created the function. So, if one sprite, say Sprite 1, has the following script:

untitled script pic (1)

and another sprite, Sprite 2, has

untitled script pic (3)

When Sprite 2's script runs, it will actually move Sprite 1 since the ring was initially created by Sprite 1. Although this is not a big deal in the Snap! setting (the above code could simply be updated so the ring is created in Sprite 2's scripting area), I find the resulting behavior a bit unintuitive in the distributed setting.

That said, a case could be made for adhering to the original semantics in the distributed case (where the sent function should control the sender's sprites). However, I am a bit skeptical of this approach (both in ease-of-use/understanding for students and implementation).

brollb commented 4 years ago

There is an automated test for this (in test/projects/send-fn-tests.xml) but it is currently skipped. The test is currently assuming that the expected behavior is to be able to move the recipient sprite with motion blocks.

DarDoro commented 4 years ago

Why did You consider this behavior as confusing? The visual metaphor of Snap! "binds" scripts to objects (sprite) they are defined in. So storing a reference to a code with the context is quite similar to well-known closures.

These methods allow fine-grained control over the context of a call. untitled script pic (23) untitled script pic (24)

brollb commented 3 years ago

@DarDoro - Good point. When this originally came up (not when I posted it but in the earlier NetsBlox days), these blocks had not been added yet as primitives (they were added in mid 2017) and I hadn't updated my mental model accordingly. :)