A few random comments from an eToy newbie

Alan Kay Alan.Kay at squeakland.org
Mon Apr 7 18:13:01 UTC 2003

Heh heh, of course the real etoy newbies (namely children) don't find 
any of these "features and bugs".

I would call what you did with the etoy system "Omniuser scripting" 
of the kind that most adults (and children older than 12) will want 
to be able to do. This is one of the goals of Andreas' Tweak 
environment: to make a graceful arc from very easy young child 
scripting to pretty easy media scripting.

There are a few comments that might help here though. Etoys doesn't 
use a Smalltalk object model, but is much more prototype oriented. So 
additions to siblings are not automatically propagated (but there is 
a menu item to do this). Thus, etoy objects can have local instance 
variables and methods. Andreas is going to provide a "factory recall" 
for propagation which will probably be more convenient.

There are no nil variables, all variables have some concrete object 
in them, and there is a rudimentary type system (which needs to be 
done better).

Parameters are not used by the children we work with -- so this is an 
unsupported feature to help us think about the syntax and semantics 
of parameters and return values. This seems like a big lack, but it 
turns out that it isn't missed for most of the children's projects. 
Most of the stuff I do is to make up project ideas for the kids so I 
don't use parameters either.  The kind of programming this leads to 
is kind of like "OO Cobol" but there is a certain ease and charm of 
just using instance variables to pass parameters and return values. 
My current thoughts are to make actual params and return values in 
the future version look more like the explicit assignments of the "OO 
Cobol Etoys" that we have now, perhaps in a case tile.

SketchMorphs shouldn't ignore the grid (and they don't on my version 
of Squeak). What's going on here? Also, I think that one of the 
original conventions was supposed to be "center of object on grid 
intersection".  Maybe Scott has some comments.



At 8:48 AM -0700 4/7/03, Ned Konz wrote:
>Here are the notes that I made when doing my "Karel's World" project.
>I realize some of this behavior is by design, but there were some eToy
>behaviors that I found frustrating, difficult, or buggy:
>Dot vs. Dot
>	When you do a test for Holder.firstElement, the Holder may be empty. In
>	this case, it returns *a* Dot.  However, this Dot is not *the* Dot.
>	Instead, it is *a* dot owned (created, in fact) by the Holder.  I
>	got confused when I started moving Dot name tiles around.
>no test for Holder.isEmpty
>	Instead of a simple test for whether a Holder is empty, you get a
>	test of whether Holder.firstElement is (or is not) "dot".
>no test for isDot (i.e. is unscripted)
>	There seem to be multiple Dots (see above) filling in for (for
>	instance) nil in cases where you have to return some default value.
>	But there's no way I could see to test for dot-ness in a script.
>Only test for firstElement ==/~= someObject
>	Should perhaps have isKindOf or isLike test? What would this 
>be (looks like/acts like)?
>No metaprogramming
>	Though phrase tiles and script editors themselves have identities
>	and viewers, and you can get tiles for them, etc., there is no way
>	to write (for instance) a script that adds to another script. I
>	wanted to have programming by example, but couldn't manage it.
>Can't get to objects via noun phrases
>	Given a noun phrase (either a tile for an object, or a phrase that
>	returns an object), how can I get to a viewer for the object (or the
>	object's costume)? It doesn't seem to be easy. Finally I made a
>	script that I could drop a noun phrase on that just did "Something
>	doMenuItem viewer". But it would be nice to be able to directly get
>	a viewer (perhaps from a context menu).
>	The only phrase-specific menu item in the halo menu, though, is
>	"sprout a new scriptor around this phrase".
>Mysterious subclassing (duplicate A twice, script one A1, other A1 
>doesn't behave similarly)
>	The structure of the various PlayerXX subclasses is not clear. It's
>	easy to write scripts in the wrong subclass after duplicating a
>	Morph.
>No return values from scripts -- second class citizens
>	How can I return a value from a script? Now that they take
>	parameters, this seems like the only limitation of a script.
>Grid behavior casual at best
>	I wanted to have a properly gridded world. This was frustrating
>	because grid handling is inconsistent and awkward:
>		- polygons snap vertices to grid
>		- move/size snaps to grid
>		- but dropping SketchMorphs ignores grid.
>		- And aligning on origins is often less convenient 
>than aligning
>		  *where the morph is picked up* with the grid (or 
>center, etc.)
>Removing projects leaves objects & classes intact (I didn't isolate 
>the project; can you do this later?)
>	Having built the project, I then wanted to load my new version for
>	testing. I got all my objects renamed (i.e. Robot became Robot2,
>	etc.) even though I'd removed the original project's window. It
>	turned out that all these objects were being pointed to by script
>	methods.
>	Didn't there used to be some way to isolate a project, or did that
>	go away with 3.3?
>Can't pick apart phrase tiles
>	Given a phrase tile that says (for instance) "Holder's firstElement
>	show", I can select a PhraseTile that says "Holder's firstElement",
>	and then duplicate that PhraseTile. However, trying to use this new
>	PhraseTile results in a walkback.
>Walkbacks on unrecognized menu items
>	If you tell an object of the wrong kind to do a menu item that it
>	doesn't provide, you get a walkback. You can do this, for instance,
>	by making a new script that has a Player parameter. Inside the
>	script, you write
>		Player doMenuItem viewer
>	When you right-button the tile ("viewer") that says which menu item
>	to perform you get a walkback.
>Ned Konz


More information about the Squeak-dev mailing list