I have not used Scratch or Snap enough to know how instance to instance communication is established. Most of the multi-objects projects in GP (like Diffusion) create lots of instances of a class and broadcast to all of them.
If you're doing storytelling, or have a small number of distinct objects that need to interact (e.g., in a user-interface with buttons and displays), you want to talk to specific objects. How do we do it in Scratch? How do we do it in GP?
Here's my request/suggestion: I'd like to be able to click under an instance in the class/instance browser, and give an instance a name, say "Pat." I'd like to be able to ask for "Pat's costume" and I'd like to be able to "tell Pat to step."
Naming instances globally?
Moderator: MSandro
Re: Naming instances globally?
This an excellent design question.
In Scratch, every sprite has a unique name and there are blocks that refer to other sprites by their names such as "touching sprite" or "x-position of sprite". Because every sprite has a name (and because there are typically not too many sprites), you can specify any sprite by name using a drop-down menu. For dealing with many instances, Scratch uses cloning, but the clones are anonymous; you can't refer to a particular clone by name (although I believe some blocks, like the "sprite touching" block, respond to any clone of the named sprite).
Names are great for projects with a fixed and relatively small number (say, a few dozen) of objects. They are not so great for projects that may involve hundreds or thousands of dynamically created objects. For example, in a rabbits-and-grass ecosystem simulation, it probably doesn't make sense to name the individual rabbits and tufts of grass since they are created and deleted dynamically as the simulation runs. (It does make sense to talk about all the objects of a particular class, such as "rabbits" or "grass". Some systems, like StarLogo TNG, uses the word "breed" instead of "class".)
Since GP is intended to scale up to larger projects, GP instances do not have intrinsic names. However, you can store a reference to an instances in a variable, thus giving you a way to refer to it by name. This currently requires a bit of planning. For example, you might use the reporter version of "instantiate" to create an instance reference that you save in a variable. If you need to refer to that object from multiple sprites, you'd use a shared variable. If you only need to refer to it from one sprite, you could use a normal variable (i.e. an instance variable or what Scratch calls a "this sprite only" variable).
Obviously using variables for naming requires a fair amount of knowledge and experience; few (if any) beginners will discover this idea on their own. One idea for helping beginners learn this technique is to provide a "name this instance" menu command exactly like the one you propose that creates a variable and initializes it to refer to that instance. This would allow the user to name instances post-facto (i.e. without having to plan ahead or use the instantiate reporter). It would also introduce the powerful idea of using variables to refer to things.
What do you (and others) think of that idea?
In Scratch, every sprite has a unique name and there are blocks that refer to other sprites by their names such as "touching sprite" or "x-position of sprite". Because every sprite has a name (and because there are typically not too many sprites), you can specify any sprite by name using a drop-down menu. For dealing with many instances, Scratch uses cloning, but the clones are anonymous; you can't refer to a particular clone by name (although I believe some blocks, like the "sprite touching" block, respond to any clone of the named sprite).
Names are great for projects with a fixed and relatively small number (say, a few dozen) of objects. They are not so great for projects that may involve hundreds or thousands of dynamically created objects. For example, in a rabbits-and-grass ecosystem simulation, it probably doesn't make sense to name the individual rabbits and tufts of grass since they are created and deleted dynamically as the simulation runs. (It does make sense to talk about all the objects of a particular class, such as "rabbits" or "grass". Some systems, like StarLogo TNG, uses the word "breed" instead of "class".)
Since GP is intended to scale up to larger projects, GP instances do not have intrinsic names. However, you can store a reference to an instances in a variable, thus giving you a way to refer to it by name. This currently requires a bit of planning. For example, you might use the reporter version of "instantiate" to create an instance reference that you save in a variable. If you need to refer to that object from multiple sprites, you'd use a shared variable. If you only need to refer to it from one sprite, you could use a normal variable (i.e. an instance variable or what Scratch calls a "this sprite only" variable).
Obviously using variables for naming requires a fair amount of knowledge and experience; few (if any) beginners will discover this idea on their own. One idea for helping beginners learn this technique is to provide a "name this instance" menu command exactly like the one you propose that creates a variable and initializes it to refer to that instance. This would allow the user to name instances post-facto (i.e. without having to plan ahead or use the instantiate reporter). It would also introduce the powerful idea of using variables to refer to things.
What do you (and others) think of that idea?
Re: Naming instances globally?
I like the 'name this instance' proposal. I know that in industrial-strength object systems, who knows which object is part of information hiding. I can see that that's the direction you're going with GP. That makes sense, but we are still dealing with intermediate programmers. Having a shortcut that establishes the connection from one object to another would be helpful.