initial feedback on v77

Questions about GP commands and how to do things

Moderator: MSandro

Post Reply
SimpleSi
Posts: 330
Joined: Jul 2nd, '17, 13:47

initial feedback on v77

Post by SimpleSi » Nov 18th, '17, 22:17

Like the simplification of broadcast in removing the destination
but...
what is the send block for then ? - it looks like the old broadcast block brought back with differerent name - I'm confused

touching edge - yippee :)

neighbours - very happy that it now returns any neighbour within the radius :)


Will have to think about losing parameters in instance initilize methods - doesn't seem like an improvement at first glance

"Increase scroll speed" - slightly better (by 20%) but still seems slow compared to other apps and progs

JohnM
Posts: 379
Joined: Sep 11th, '15, 14:42

Re: initial feedback on v77

Post by JohnM » Nov 20th, '17, 18:58

You're right, the "send" block does what broadcast used to do -- it allows you to send a message to a sprite or list of sprites (with an optional "data") parameter. Broadcast now means "everyone", as in Scratch. My hope is that this will the simple cases of broadcast easier to understand/discover for beginners, especially those coming from Scratch. It also makes code using broadcast/send easier to read at a glance; "broadcast" always means "to everyone", "send" means "to an individual instance or a list of instances". For example, "send" might be combined with the "neighbors" block to send a message only to nearby instances.
Will have to think about losing parameters in instance initilize methods - doesn't seem like an improvement at first glance
One thing it simplifies is the use of the "+" button to make new instances. With the old scheme, if the initialization method depended on its parameter in some way, then creating a new instance would be "nil" as the parameter, often leading to errors. One could, of course, add a test to the initialization method for the parameter being nil, and use some default value in that case, but how would a beginner know they had to do that? I think it's better to make basic initialization of an instance be parameterless so beginners can learn to use the simple case of initialization, which is often useful just for things like the setting the costume, before moving on to more complicated cases.

There are at least three ways you can deal with the more complicated cases.

1. Supply the initialization parameters via global variables. See the ElectricField demo project for an example.
2. Use "send" to send a message to the newly created instance. See the BubbleTrails starter project for an example.
3. Create a "setup" method for your class and call that method on the newly created instance. This allows you to pass multiple initialization parameters with nice labels, but it requires a bit more setup that the other two techniques -- you need to create the setup method and possible export it to the palette if you need to call it from another class.

None of these techniques is difficult or time-consuming, although they are also not "obvious" or easy to discover, although documentation and example projects may help. Furthermore, to use the old parameterized initialization safely, one needed to add code to deal with the possibility of a missing parameter, a case that was easy to trigger simply by clicking the new instance button -- or even when the system creates an instance automatically for you. It would at least as difficult for a beginner to discover how to fix the resulting error as it would be for them to discover how to supply a parameter with the new design, but they would run into the problem sooner, and getting errors -- especially when you don't understand why -- is frustrating and can be demoralizing.

In short, using initialization parameters will require learning something non-obvious; the new design is intended to allow beginners to learn about the simple case first, with less chance of getting errors that are difficult to understand. When they do need parameters, they may need to look around (or ask) to figure out how to do that, but they are more likely to ready the learn more at that point -- and solutions (1) and (2) building on concepts they are probably already familiar with: global variables and message send/receive.

This thinking about initialization grew out of direct experience with users at a recent GP workshop that made the shortcomings of the old design very clear. There may well be problems with the new design as well, but we won't really know until we try it with a few sets of new-to-GP users.

Post Reply