[Squeakland] Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script
scott.wallace at squeakland.org
Tue Nov 14 04:54:48 PST 2006
On Nov 13, 2006, at 8:21 AM, Offray Vladimir Luna Cárdenas wrote:
>> When you execute "Car's copy", the result will be the creation of a
>> copy of Car (strictly speaking a "sibling", viz. a fellow instance of
>> the same class as Car.)
>> However, if you don't *place* that copy somewhere, you won't see it.
>> The standard idiom for placing an object somewhere via script is to
>> tell the *container* in which you place it to "include" it.
>> Here's a typical usage pattern:
> This works pretty good. I use the world as a container and now I
> have a
> lot of stars in the wold. At the beginning I thought it was not
> because all starts were copied over the original one, but then I
> realized what was happening. There is still something I don't know how
> to do: how can I send a message to a particular copy. Suppose I have
> copied a Car and I have a script for the original one to make the
> go forward and now I wan to make the recent copy to use that script.
> There is some natural number in each of the copies' names. Can I
> use it
> as a reference for the copies scripts to enable them?
The trick here is to assign the newborn to a "player-valued" variable
belonging to the object that creates the newborn. That gives you a
way to refer to the it. (To create a player-valued variable within
an object, first hit the V button at the top of the viewer to add a
variable; give it a name; then from its menu, choose "change value
type" and from the pop-up of available types, choose Player.)
Thus, if the birthing script belongs to an object named "Foo", and
that the script you want the newborn to run is called "zork".
Foo's newborn := Car's copy. "creates the newborn and
stashes it in a variable belonging to Foo"
World append: Foo's newborn. "add the newborn to the world"
Foo's newborn zork. "have the newborn run its zork script"
There is an awkward and non-intuitive construction necessary to build
"Foo's newborn zork". To do this right now, the usual way is to get
a "Foo's zork" statement, and then grab a "Foo's newborn" tile from
the "variables" section of Foo's viewer, and drop it on top of the
"Foo's" in "Foos zork", thus making "Foos' newborn's zork". The
meaning of this construct is" "Send the message #zork to the object
referred to by the value in Foo's variable named 'newborn' ".
One common use for this approach, since newborns created with "copy"
will typically pile up all in the same location, is to have the post-
birth code move the newborn a small distance away from the donor, and
perhaps make some further adjustments to the newborn to give it a
good start in life. I attach a tiny project that illustrates this
use. Every time you click on an object, it gives birth to a new
object, which starts out life at the same location as its parent, but
is given its own heading and a slightly increased speed.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 52857 bytes
Desc: not available
Url : http://squeakland.org/pipermail/squeakland/attachments/20061114/04758910/birthOnClick-sw.001-0001.obj
-------------- next part --------------
>> Secondly [and this is not so well known] you can open a conventional
>> Smalltalk browser on the class of an etoy "object", and using that
>> Browser you can not only see and edit the etoy scripts, you can also
>> add any other methods you wish, including methods with multiple
>> arguments (whereas etoy scripts are limited to 0 or 1 argument,)
>> mid-method returns, and many other things that you can't directly
>> obtain using tiles alone. To get such a Browser, in the Viewer's
>> choose "more..." and from the auxiliary menu that pops up, choose
>> "browse class."
> On this point this is what I get:
> browser class
> There is a #guión1 (#script1) but I don't know how to change scripts
> code or add new scripts. Any pointer to the documentation?
Ah, well, this is a standard Smalltalk "class browser". To get
involved earnestly at this level, one is going to need to learn how
to use the tools of the Smalltalk IDE such as the Browser. Once you
start adding new methods to an object in this way, you are basically
dropping through a trap door into a fabulous, boundless, but much
less sheltered, world. A
There is presently no documentation I know of that is specifically
aimed at etoy users which covers things like the Smalltalk browser.
So I would again refer you to some of the excellent, free Smalltalk
books available online.
However, here are a few hints to get started working in a Smalltalk
browser opened by an object's Viewer as we've been discussing, if you
want to try to feel your way through:
(1) To change the code of a script, such as your #guión1, click on
its name in the upper-right-pane of the browser. This will showing
you the existing code of the script, in textual form, whether or not
the script is currently officially designated as textually-coded.
Then you text-edit the code in the usual way, and then to *submit*
the code you type alt-s.
(2) To add a new method that is visible within the tile-scripting
world, first choose the "selector" (method name) you want to use,
then add an etoy script and give it that name. If it is to have a
parameter, add it. You can subsequently textually edit the code
either in the Scriptor (after you've switched the Scriptor from tiles
to text) or in a full textual Smalltalk Browser.
(3) To add a new method which will operate outside the ken of the
tile-scripting world (e.g. you won't see it in a Viewer): this one
needs to be done using the Browser. Get a Browser for your object
("browse class" from its Viewer's more... menu), click on == all --",
then, in the code pane which will now show a method template whose
first line says "message selector and argument names, select all the
text and hit backspace, to clear out the area, then type the new
script, starting with the selector and formal arguments, then the
temps, then the body of the method -- use the patterns you see when
browsing the code of other objects in the system to see how these work.
Why would one want to write scripts for an object which operate
completely outside the etoy framework? For one thing, etoy scripts
can have at most one argument, and their arguments normally need to
conform to one of the formal etoy types.
> Cheers also from the country of the birds (well the second one).
> you want come, you must be aware: mi casa es tu casa (my home is
> your home),
Thank you ! I'm going to take you up on that offer one of these
More information about the Squeakland