Hi,
In Etoy viewers, some of the slots like bearingTo don't have watchers on them. They don't act like number tiles in assignments. It is disturbing to drop them into assignments and not be able to append arith operators. Is this because of computational load?
If so, could a different icon (say yellow menu instead of a white one) be used for such slots?
Subbu
Hi, I haven't noticed this before, but I think this is a bug. It should behave like a regular slot and it shouldn't have a different icon I think. If a watcher is not possible because of computational load you should at least be able to append operators. When you drop it on a test tile it doesn't append comparison operators so you end up with a NonBooleanReceiver error. I don't know how to fix it, I tried to add the watcher by modifying #phraseForVariableFrom: but it didn't work quite well. Perhaps someone more experienced than me should take a look at this.
Cheers.
On Fri, Sep 25, 2009 at 11:43 PM, K. K. Subramaniam subbukk@gmail.comwrote:
Hi,
In Etoy viewers, some of the slots like bearingTo don't have watchers on them. They don't act like number tiles in assignments. It is disturbing to drop them into assignments and not be able to append arith operators. Is this because of computational load?
If so, could a different icon (say yellow menu instead of a white one) be used for such slots?
Subbu _______________________________________________ etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Saturday 26 Sep 2009 9:41:11 am Ricardo Moran wrote:
Hi, I haven't noticed this before, but I think this is a bug. It should behave like a regular slot and it shouldn't have a different icon I think.
Vocabulary>>gettersForbiddenFromWatchers contains a list of getters that don't have watchers, Both addWatcherItemsToMenu:forGetter: and morphToDropInPasteUp: (used in tile scripts) filter out these getters. So it is a deliberate action.
I just couldn't figure out the rationale .. Subbu
On 26.09.2009, at 04:43, K. K. Subramaniam wrote:
Hi,
In Etoy viewers, some of the slots like bearingTo don't have watchers on them.
Requiring an argument, these are not slots, but functions. Not having a read-out on them is intentional.
Is this because of computational load?
I don't think so, but maybe Scott can enlighten us on the design reasoning? I think it made sense that only properties of the object itself have read-outs, not relationships to its environment.
They don't act like number tiles in assignments. It is disturbing to drop them into assignments and not be able to append arith operators.
That's just a bug. Please file a ticket.
If so, could a different icon (say yellow menu instead of a white one) be used for such slots?
Maybe, maybe not. Having a lot of different icons might be confusing, too?
- Bert -
On 26.09.2009, at 11:25, Bert Freudenberg wrote:
On 26.09.2009, at 04:43, K. K. Subramaniam wrote:
Hi,
In Etoy viewers, some of the slots like bearingTo [...] don't act like number tiles in assignments. It is disturbing to drop them into assignments and not be able to append arith operators.
That's just a bug. Please file a ticket.
I filed it, this is important:
http://tracker.squeakland.org/browse/SQ-450
- Bert -
On 2009-09-27 15:38, Bert Freudenberg wrote:
On 26.09.2009, at 11:25, Bert Freudenberg wrote:
On 26.09.2009, at 04:43, K. K. Subramaniam wrote:
Hi,
In Etoy viewers, some of the slots like bearingTo [...] don't act like number tiles in assignments. It is disturbing to drop them into assignments and not be able to append arith operators.
That's just a bug. Please file a ticket.
I filed it, this is important:
http://tracker.squeakland.org/browse/SQ-450
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
We have the same issue with distanceTo
Karl
On Sat, Sep 26, 2009 at 6:25 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 26.09.2009, at 04:43, K. K. Subramaniam wrote:
Hi,
In Etoy viewers, some of the slots like bearingTo don't have watchers on them.
Requiring an argument, these are not slots, but functions. Not having a read-out on them is intentional.
Is this because of computational load?
I don't think so, but maybe Scott can enlighten us on the design reasoning? I think it made sense that only properties of the object itself have read-outs, not relationships to its environment.
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.
Cheers
They don't act like number tiles in assignments. It is disturbing to drop
them into assignments and not be able to append arith operators.
That's just a bug. Please file a ticket.
If so, could a different icon (say yellow menu instead of a white one) be
used for such slots?
Maybe, maybe not. Having a lot of different icons might be confusing, too?
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
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. With computations, one is not sure about side effects. One can always create a variable and use a script to track the changes through this variable.
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 :-(.
How about using round edges or changing color of computed tiles?
Subbu
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
On Tuesday 29 Sep 2009 6:10:07 am Ricardo Moran wrote:
On Mon, Sep 28, 2009 at 8:17 PM, K. K. Subramaniam subbukk@gmail.comwrote:
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.
That may be your expectation. I am only speculating on the designer's intention.
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.
Etoys is a prototype-based environment built in Squeak. I am speculating about designer's intention about readouts based on my reading of the code.
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.
In Etoys, "variables" are passive containers of values with getters and setters, nothing more. It is true that functions computed on the state of a Etoy can yield varying values but the code seems to treat such computations differently.
Let us wait for Scott Wallace or one of his "water-cooler" mates to post a response, Subbu
There's no deep reason why "slots with arguments" don't have readouts in the Viewer, nor why stand-alone Watchers aren't available for such slots. Both would be desirable enhancements.
The side-effect concern afaik would only apply to the "Car's copy" tile; we can't be calling this repeatedly, since each call creates a new copy. But with that exception (already strange in other ways,) it would be desirable to have readouts for all slot-like entities, whether or not they involve parameters.
Performance considerations may make us ultimately decide to refrain from showing readouts in viewers for certain slots, but even for those slots involving "expensive" computations, I think ideally we should still allow the user to obtain stand-alone watchers for them.
-- Scott
On Sep 28, 2009, at 5:40 PM, Ricardo Moran wrote:
On Mon, Sep 28, 2009 at 8:17 PM, K. K. Subramaniam subbukk@gmail.com wrote: 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
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Scott Wallace wrote:
There's no deep reason why "slots with arguments" don't have readouts in the Viewer, nor why stand-alone Watchers aren't available for such slots. Both would be desirable enhancements.
The side-effect concern afaik would only apply to the "Car's copy" tile; we can't be calling this repeatedly, since each call creates a new copy. But with that exception (already strange in other ways,) it would be desirable to have readouts for all slot-like entities, whether or not they involve parameters.
Performance considerations may make us ultimately decide to refrain from showing readouts in viewers for certain slots, but even for those slots involving "expensive" computations, I think ideally we should still allow the user to obtain stand-alone watchers for them.
I'm not sure if I understand how these things work, but I just had an idea. Would it be possible to write a description about how a user can add a watcher to a given tile? Using Squeak, class browser , writing Smalltalk code? Could that be one path to learn how to program for interested high school students?
Rita
-- Scott
On Sep 28, 2009, at 5:40 PM, Ricardo Moran wrote:
On Mon, Sep 28, 2009 at 8:17 PM, K. K. Subramaniam subbukk@gmail.com wrote: 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
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
K. K. Subramaniam -
Karl Ramberg -
Ricardo Moran -
Rita Freudenberg -
Scott Wallace