[etoys-dev] Slots without watchers

[Scott Wallace]

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 at 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 at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev