Yes, Brian, I agree that it would be nice for a clone to be able to both inherit scripts and also be able to override individual ones and add other ones not present in the parent. The more I work with inheritance myself script inheritance turns out to be the part I actually love the best. And once you do that it's obvious that a more fine-grained distinction would be really, really, neat. Let's think about this!

Hi Jens ,

There is “still” a vocabulary issue. When talking of “clones” you have two categories. On one side “created-clones” (by a command inside a sprite like “create a clone of…” ). And on the other side “duplicated-clones” created inside the sprite-corral.

If you make a crowd of dup-clones and you need after to add a new piece of script (hat command for example) you have to add it, one by one, to each dup-clone.With a created-clone any script added is available for all clones, But reversely created-clones are lost when the project is saved.

xly wrote:

Hi Jens ,

There is “still” a vocabulary issue. When talking of “clones” you have two categories. On one side “created-clones” (by a command inside a sprite like “create a clone of…” ). And on the other side “duplicated-clones” created inside the sprite-corral.

If you make a crowd of dup-clones and you need after to add a new piece of script (hat command for example) you have to add it, one by one, to each dup-clone.With a created-clone any script added is available for all clones, But reversely created-clones are lost when the project is saved.

Maybe you're thinking of duplicated sprites, which aren't the children of the sprite you duplicated. If you right-click on a sprite and click “clone” then it will inherit all the scripts from its parent, but if it doesn't you just need to right click on the scripting area and check “inherited”. (These are the replacement for BYOB 3 clones as far as I know.)

Jonathan50 wrote:

(These are the replacement for BYOB 3 clones as far as I know.)

Right, we have two different kinds of clones:

1. Scratch-style: Temporary, not in sprite corral, you can have lots of them and it's still fast.

2. BYOB-style: Permanent, appear in sprite corral, have their own scripting area, but still can inherit stuff from parents.

Sprites created programmatically are by default temporary. Sprites created using the “clone” command in the right-click menu of a sprite are by default permanent. Changing a clone from permanent to temporary is easy (although the command to do it is peculiarly named). Changing a clone from temporary to permanent requires calling up Jens at home for permission, because he's worried that people will make too many permanent ones and their projects will slow down and they'll be upset.

In principle, clones should initially inherit /everything/ (why won't it let me use italics today?) from their parent, but that would break too many Scratch projects. I'm trying to convince Jens that if that's the reason, we should have BYOB-style clones inherit everything, and make that change quickly, before too many /Snap!/ projects get broken.

Snap has clones, period. Not “two kinds” of clones. Clones can inherit properties of their parent, i.e. variables, custom blocks, attributes, costumes, sounds, scripts, in other words: “slots”.

There is only one kind of clones, not “Scratch-style” or “BYOB-style”. Whether a clone gets automatically deleted when the red stop sign button is pressed depends on whether the user has edited it or not. As soon as you edit a clone it won't disappear automatically, because we don't want users to accidentally lose their work. You can edit a clone either by explicitly creating it in the GUI, e.g. by right-clicking on a sprite or a sprite-icon in the corral and choosing “clone”, or - in case the clone has been created programmatically - by choosing “edit” in the clone's context menu. When you do that the clone also gets its own sprite-icon in the corral. This will make the clone permanent (and immune to the “delete this clone” command). You can then save and re-open the project and the clone is still there. If, in turn, you would like to make and edited clone temporary again you can choose “release” in the context menu of its sprite-icon the corral.

Jens wrote:

There is only one kind of clones, not “Scratch-style” or “BYOB-style”. Whether a clone gets automatically deleted when the red stop sign button is pressed depends on whether the user has edited it or not. As soon as you edit a clone it won't disappear automatically, because we don't want users to accidentally lose their work.

No, Jens, I don't think that's a fair presentation of our thinking about this. Edited clones, as you put it, are permanent not only “because we don't want users to accidentally lose their work.” There really are two theoretical models behind these two behaviors.

In BYOB 3.1, all clones were permanent, and the hierarchy was explicit in the sprite corral – you could click on a sprite to see its children, and then click on a child to edit it. (Is this use of “edit” something Scratch people say, by the way? I find it a little confusing because it makes me think about opening a Block Editor.) The model is Lieberman prototyping: Every sprite is both a class and an instance, in that it has methods and can pass them on to its children, but also has instance variables and a concrete presence in the world, i.e., is onstage. All sprites are in the same category, including the one you see when you start a new project. Historically, this was the /first/ use of cloning, rather than just duplication, in Scratch-ish software.

Then came Scratch 2.0, with a very different model, in which clones are in a semantically different category from “real,” primary sprites. They're temporary; there is no hierarchy (if you clone a clone, what you get is a direct clone of the primary sprite); a clone can have its own instance variables but not its own methods.

You fell in love with Scratch-style cloning, and it was relatively easy to implement, so you just did it, in Snap! 4.0. Much later, in 4.1, you implemented BYOB-style cloning, but with a major restriction: you can't create BYOB-style clones programmatically, and you can't turn a Scratch-style clone into a BYOB-style clone programmatically, for speed reasons, not intellectual reasons. Internally, the two kinds of clones have a lot in common, but they are still quite different as seen by users. The two behaviors are based on two different intellectual histories; the difference is not a small thing to be handwaved away in how we describe them to users, especially since users can't change from one behavior to the other programmatically. Otherwise, there would be no reason why editing a clone should make it appear in the sprite corral! It's a real category shift. There would be no reason why MY CLONES reports only the temporary ones and there's a separate MY CHILDREN for the permanent ones.

I feel like much of the confusion with clones could be solved with some GUI changes.

Out of curiosity… What is the difference between the “clone” and the “duplicate” context menu options? The only difference I've found is that "my [parent]" returns a different value.

PullJosh wrote:

I feel like much of the confusion with clones could be solved with some GUI changes.

Could you be more specific? The two GUI changes I want are to change the names “edit” and “release” to “→permanent” and “→temporary”; and the long-awaited 3-D sprite corral (so top-level sprites are displayed by default, but in the context menu for a sprite you can ask to see its children). Mostly what I want are changes to the primitives.

Out of curiosity… What is the difference between the “clone” and the “duplicate” context menu options? The only difference I've found is that "my [parent]" returns a different value.

A duplicate is a new copy of the sprite, but with nothing shared. Changes to the original are not passed on to the duplicate, whereas they are to a clone. (Except that not all attributes are shared by default; methods are, but local variables aren't. This is to avoid breaking Scratch projects. I'm advocating for a Flag Day in which we change the version number on saved project files and introduce bunches of Scratch incompatibilities at once, while automatically loading a Scratch compatibility library for projects with the old version number or converted from Scratch, e.g., angles counterclockwise from East, non-numeric values in numeric slots are runtime errors rather than zero, etc. And also all attributes are shared by default. (I don't personally care about the angles thing either way, but it's probably the most common complaint we get from teachers.))

Brian wrote:

No, Jens, I don't think that's a fair presentation of our thinking about this. Edited clones, as you put it, are permanent not only “because we don't want users to accidentally lose their work.” There really are two theoretical models behind these two behaviors.

Actually, that's not right. Snap has clones, and clones now have been enhanced with Lieberman-style inheritance. There is exactly one single coherent inheritance model for all clones, and - that's the beauty - it's compatible with previous projects. Also, you have control over whether a clone is temporary or not, and you can toggle that at any time as much as you want. The only thing I won't let you do (for now) is make clones permanent using a built-in primitive in user-mode (there is a “is temporary?” setting in dev mode and you can write a JS function for a library). And yes, the reason totally is that I don't want users to lose their work, that's why editing a clone prevents it from being automatically or programmatically deleted.

bharvey wrote:

PullJosh wrote:

I feel like much of the confusion with clones could be solved with some GUI changes.

Could you be more specific?

Sorry; I was originally typing up my post to include more details, until I came across the clone/duplicate confusion. Although you've pretty much nailed everything I was going to recommend in your own post.

The most useful UI change, I think, would be to nest cloned sprites beneath their parent inside the sprite thumbnail area (does that panel have a name?), as well as rename a few context menus (especially the “permanent” and “temporary” options you mentioned).

@Jens While I have no doubt that you're correct about the way that clones are implemented, I can tell you that as a user they feel like two very distinct things (even before I started reading Brian's ramblings.) Honestly, reorganizing the UI to make the similarities between types of clones more clear would be hugely beneficial in clearing up the confusion. (Although that's just my two cents.)

Just for good measure, here's a very rough mockup of how I envision the sprite panel looking:


Any sprite which is a parent to at least one clone would have a dropdown arrow (or possibly a more easily-understandable button) which would open up a panel of clone sprites when clicked.

Edit: Looks like in my mockup I forgot to include top-level sprite #5. Pay no attention to that.

PullJosh wrote:

(does that panel have a name?)

We call it the “sprite corral.” And your mockup is more or less the long-awaited “3-D sprite corral.” It's really 3-D, not just 2½-D, because the permanent clones can have children of their own, so in principle the hierarchy could be indefinitely deep.

Jens wrote:

There is exactly one single coherent inheritance model for all clones, and - that's the beauty - it's compatible with previous projects.

I agree with the first part of this: there is one inheritance model. If you just think about inheritance, the two kinds of clones are the same. But if you think at all about interacting with them, they're quite different. Most importantly, you can't make permanent ones programmatically – which means that the current implementation, while compatible with /Scratch/ projects, is /not/ compatible with /BYOB/ projects. But also
* Temporary clones aren't in the sprite corral.
* Temporary clones are killed by DELETE THIS CLONE.
* Temporary clones can be created by the CLONE block.
* Temporary clones have only siblings, not children.
* Temporary clones are killed by the Stop button.

As far as the user is concerned, these two types of clone are much more different than they are the same.

I'm not really sure why we're having this argument, since you agreed with this when we last talked f2f. And it's what's in the manual, and you didn't complain about that.

What would this:
Sprite1 Sprite2
/ \ |
Sprite3 Sprite4 Sprite5
/ \ \
Sprite6 Sprite7 Sprite8

look like in the 3-D sprite corral?

Yas some new coding websites!

 continue this hashtag if you live in australia [img]http://u.cubeupload.com/rabbitcarrots/FEDB1435D41540BFB9FB.jpeg[/img] is the image code xD oh and btw this siggy is from @Hellounicorns2    :cool:

Jonathan50 wrote:

What would this:
Sprite1 Sprite2
/ \ |
Sprite3 Sprite4 Sprite5
/ \ \
Sprite6 Sprite7 Sprite8

look like in the 3-D sprite corral?

It would show Sprite1 and Sprite2. Clicking the downarrow or whatever on sprite1 would show 3 and 4. Clicking the downarrow on 4 would show 8. Etc.

Actually the way it worked in BYOB was that all the clones were in the corral, but you could right-click on a sprite with children and choose “children”…

… you'd get a white box with its children…

and then if you click on one of the children in the white box…

… you would get a new white box with its children (and focus would shift to the one you clicked – notice that Sprite3 is now selected in the corral).

I don't know why the sprite names in the white boxes look so awful; I'm pretty sure they didn't before. Maybe something about retina displays?

@ Jens & Brian

I don't think it is necessary to substantially modify the corral as it is suggested.
A Snap! programmer has just to know the difference between “clones” and “clones”.
Personally , although being an user of clones I did not know some of their features I've learnt thanks to our present discussions.
While revising some project clone-intensive I have observed that older projects (one year old) do not propose the “edit” choice in the right-click menu .

temporary clones can have children

Jens wrote:

temporary clones can have children

Ah, sorry, my bad. I was confused because if you make one clone, and ask it to make one clone, then MY CLONES is of length 2, even though MY CHILDREN is of length 1.

This is an - admittedly subtle - twist to stay compatible with the Scratch cloning model. In Scratch there is only one level of clones, cloning a clone creates a clone of the original sprite. But - here's the point - it *doesn't matter* at all, because Scratch doesn't have inheritance (Scratch does share scripts among all clones, but since it's impossible to override the scripts of a single clone hierarchies don't matter).

Hey, gang, please try out http://snap.berkeley.edu/crayons.xml, which provides a “box” of 100 “crayons” as an alternative to hue numbers. The main block, under Pen, is

but there's also CHANGE CRAYON BY (very slow at the moment because libraries can't yet make global variables, and so it has to figure out what your current crayon number is).

Here are the design goals of this library:

1. The actual spectrum is ridiculously green-heavy. This crayon box includes 15 shades of gray (0=black to 14=white), five pinks (I hate pink), and then 10 each of red, brown, orange, yellow, green, cyan, blue, and violet.
2. If you start at 0 and increase by 10, you get a good set of ten colors, basically an augmented rainbow.
3. If you start at 0 and increase by 5, you get a good set of 20 colors, basically two of each flavor; the ones that aren't multiples of 10 are darker or lighter as appropriate.
4. If you start at 0 and increase by either 5 or 10, you never get white, so you don't draw invisible pictures.
5. The colors are all pretty saturated, neither very near white nor very near black, apart from the grey range. I think this best fits the “crayon” metaphor.


Some but not all of the colors are “official” X11/HTML colors. (Eventually I'll get around to adding a block that knows about all the X11 color names.) The non-X11 crayons came from various lists out on the web. (Did you know there's a color wiki on wikia.com? News to me.)