hi
I was showing to a teacher how to use make siblings and we were confused by the behavior. Is there somewhere a description of the difference between copy and make siblings. Apparently the behavior (duplicate) changed between 3.6-3.7 and 3.8. in 3.8 this is now make siblings by default. I checked a bit and it seems that indeed all the siblings are sharing the same behavior and the variables are local to each object.
So one teacher asked me how to get back the default copy behavior I browsed in the halos menus but I could not find that anymore. So what is the status of the makesibling/copy behavior? Is copy simply deprecated (which makes sense to me).
Stef
Hi, Stéphane, and all,
Is there somewhere a description of the difference between copy and make siblings?
Thank you for this reminder! Here's a first draft of an explanation; in this form, it will probably only be intelligible to people already familiar with the concepts of class and instance, but I hope this provides a useful point of departure.
There are two different kinds of "copying" available in the morphic etoy user-interface, here for convenience called "make-deep-copy" and "make-sibling-instance."
Both of these create clones of the original object, with exactly the same appearance, structure, state, and behavior.
The main difference is that a "deep-copy" has no ongoing affinity to the original, so that no code or structure change to the original will affect the copy in any way, and conversely no change to the copy will affect the original, whereas a "sibling-instance" is another instance of the original's uniclass, so that when you add, delete or change any script in either one, the change is instantly felt by the other (and by all other siblings,) and when you add, delete, rename, or change the type of an instance variable of any one, the structural change is immediately propagated to all of its siblings.
Another difference is that there are various scripting commands (in the "scripting" category of a Viewer) and scripting controls ("apply my status to all siblings" menu command available in the "when should this script run" menu of any script, as seen in a viewer, scriptor, or other tool) which allow communications to be made to all siblings. These apply only to true siblings, and not at all to copies, no matter how similar, made via the bright-green "duplicate" halo handle.
Though as usual we thirst for better names, arguably both ways of manufacturing a new object by copying from an existing one are needed.
There are various ways a user can obtain each kind of copy; here are a few that have "always" been available (i.e for at least the last five years) and are still available in exactly the same ways in 3.8:
To get a "deep-copy": * Drag from the bright-green halo handle. * Choose "duplicate" from the "halo actions" submenu of the red halo menu.
To get a "sibling instance": * Choose "make a sibling instance" or "make multiple siblings" from the "siblings" submenu of the red halo menu. * Open a viewer on the object (e.g. Car), go to the "miscellaneous" category of the Viewer, and find the "Car's copy" phrase and then... - Choose "give me a copy now" from the phrase's menu. - Or run a script containing a "Car's copy" phrase.
-------
Notice that in the above, the only kind of copy obtainable directly from a halo handle has been the "deep-copy" of the bright green handle, whereas the only kind of copy obtainable from an etoy script or viewer is a "sibling-instance", which has had no halo-handle counterpart.
In practice, once you have scripted a morph (i.e. given it variables or scripts or both,) what you almost always actually want, when you want a copy, is a sibling instance, rather than a deep-copy. So it has always been a problem that the bright green "duplicate" handle is so tantalizingly beckoning in the halo, whereas make-sibling-instance has had to be fished for in a submenu of a menu.
The change made in 3.8 is that once an object has been *scripted*, the halo handle seen at the top-right of its halo will now be an olive colored handle whose operation makes a sibling-instance rather than a deep-copy.
Note that the deep-copy alternative is still always available, via "halo actions... duplicate", it's just that you have to fish for it in the menu of a scripted object, just like you have to fish for the make-sibling alternatives in the menu of an unscripted object.
This is obviously not a perfect solution, but it does now make the most-likely-desired duplication operation be the easiest one to obtain, while making the alternative operation still available from the halo menu.
Cheers,
-- Scott
At 9:33 AM +0100 12/22/04, stéphane ducasse wrote:
hi
I was showing to a teacher how to use make siblings and we were confused by the behavior. Is there somewhere a description of the difference between copy and make siblings. Apparently the behavior (duplicate) changed between 3.6-3.7 and 3.8. in 3.8 this is now make siblings by default. I checked a bit and it seems that indeed all the siblings are sharing the same behavior and the variables are local to each object.
So one teacher asked me how to get back the default copy behavior I browsed in the halos menus but I could not find that anymore. So what is the status of the makesibling/copy behavior? Is copy simply deprecated (which makes sense to me).
Stef
Hi scott
I digested quite well your explanation (in fact this was what I thought).
I was always thinking that halo actions would not contain copy *and* make a sibling.
The change made in 3.8 is that once an object has been *scripted*, the halo handle seen at the top-right of its halo will now be an olive colored handle whose operation makes a sibling-instance rather than a deep-copy.
and in addition this is what confused me. I was looking anymore at halo actions since I thought that I would get all the time the make-sibling (and not copy). What pierre-andre was suggesting was to have make-sibling per default and with with plus green halo copy. this way you do not have to go into the halo menu mess.
Stef
Hi Folks --
Actually, this is all being thought through once again as we try to design and build the "Omniuser Authoring System" of which the next version of the kids' etoys system should be a subset.
I think that copy actions are too cavalier on the one hand, and classes are too top down and rigid on the other. We need something in between these two extremes. E.g. I would like to be able to "promote" an example player to being a "source" for instances. I think this will call for several UI changes, including ways to mark and find the "sources".
Ideas?
Cheers,
Alan
At 06:34 AM 12/26/2004, stéphane ducasse wrote:
Hi scott
I digested quite well your explanation (in fact this was what I thought).
I was always thinking that halo actions would not contain copy *and* make a sibling.
The change made in 3.8 is that once an object has been *scripted*, the halo handle seen at the top-right of its halo will now be an olive colored handle whose operation makes a sibling-instance rather than a deep-copy.
and in addition this is what confused me. I was looking anymore at halo actions since I thought that I would get all the time the make-sibling (and not copy). What pierre-andre was suggesting was to have make-sibling per default and with with plus green halo copy. this way you do not have to go into the halo menu mess.
Stef
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
On Wednesday 22 December 2004 12:33 am, stéphane ducasse wrote:
I was showing to a teacher how to use make siblings and we were confused by the behavior. Is there somewhere a description of the difference between copy and make siblings.
Copy (green halo handle, "Duplicate") is now the default for an UnscriptedPlayer, that is, one without scripts or variables). For an unscripted player, "duplicate" and "make a sibling" do exactly the same thing.
In the case of such a morph, this merely duplicates the Morph. Since there isn't a Player uniclass this doesn't have to get copied.
In the case of a scripted player, duplication also copies the Player uniclass, making a separate class. This used to be the default for the green halo handle. It is now harder to get to for a scripted player; you can do so via the red halo menu/halo actions/duplicate.
Make a sibling (olive halo handle) uses the same Player uniclass, if any. So changes to scripts or instance variables are shared by all the siblings. This is the same thing (and is implemented) as having multiple instances of a given class in Smalltalk.
This is now the default for scripted players.
Apparently the behavior (duplicate) changed between 3.6-3.7 and 3.8. in 3.8 this is now make siblings by default. I checked a bit and it seems that indeed all the siblings are sharing the same behavior and the variables are local to each object.
Yes, this is most often what is wanted.
So one teacher asked me how to get back the default copy behavior I browsed in the halos menus but I could not find that anymore. So what is the status of the makesibling/copy behavior? Is copy simply deprecated (which makes sense to me).
It's still there in the menu, but 2 levels deep in the red halo menu: "halo actions/duplicate".
Also, the "copy" property/command in the Etoy vocabulary creates a sibling.
squeakland@lists.squeakfoundation.org