On Mon, Sep 28, 2009 at 8:17 PM, K. K. Subramaniam subbukk@gmail.comwrote:
On Tuesday 29 Sep 2009 1:36:53 am Ricardo Moran wrote:
I don't see why a function shouldn't have a readout. It returns a value, and IMHO all useful values should have readouts. This includes bearingTo, distanceTo, isOverColor, colorSees, overlaps, overlapsAny, and so on. I know some of them can't have readouts because of performance issues but
if
bearingTo is not the case I think it should have one.
I expect watchers are only for variables/properties.
I'm sorry but I disagree. I expect watchers for anything that will return a value. When I ask for the distance to an object I care about the value, so I expect to have a watcher. When I ask an object to turn 90 degrees I only care about the movement of the object, so I don't expect to have a watcher.
With computations, one is not sure about side effects.
I also don't think any of the functions I mentioned above should have side effects, so the only reason I found for not having readouts is performance.
One can always create a variable and use a script to track the changes through this variable.
I know it's easy to use a variable to track the changes but I don't think this is what I would expect.
There is a bigger issue that will confuse young kids. The viewer has three types of slots - commands, variables and computations but they map to only two types of menu buttons. The "observation" category also includes variables with watchers, so not all relationships are computed :-(.
Maybe I'm wrong but I don't make the distinctions you made (and I don't think children do it either). When I work with Etoys I think about variables and commands. Nothing more. Clearly, "turn" is a command. And the distance to an object, at least for me, is a variable.
How about using round edges or changing color of computed tiles?
I believe a lot of different tiles would be more confusing for children.
Cheers
Subbu