[Etoys] type clash in viewer slots

Scott Wallace scott.wallace at squeakland.org
Fri Jun 6 04:43:05 EDT 2008

On Jun 5, 2008, at 10:55 PM, K. K. Subramaniam wrote:

> I had a viewer spec for #input category for a new Morph
> 	slot resolution 'Resolution in dots per inch' aNumber Player  
> getResolution
> Player setResolution:
> This code worked fine in Squeakland image but failed in Etoys image.  
> Etoys had
> another slot with the same name in VideoMorph so the type returned  
> for my
> slot was incorrect - there was no warning of a clash. I had to change
> resolution to dpi to get the code to work.
> I thought a slot is a visual wrapper for a property. Why should its  
> name be
> unique across classes? Is this a bug?
> Subbu

The key is to use a unique *getter*.  It's okay for the slot-name as  
seen by the user to conflict with a differing use of the same slot  
name by a different kind of morph, as long as the getters are unique.   
Since VideoMorph has already co-opted "getResolution" to be the getter  
for a slot of type "ImageResolution", you need to define a different  
getter to be associated with your desired type.

A viewer for your new kind of morph would then show "resolution" as a  
numeric-valued slot, coupled with its own help-message.  Your slot  
declaration and VideoMorph's slot declaration would not clash, because  
the slots in a player's vocabulary are indexed by getter, not by  
externally-visible name.

Thus, in your example, you might decide to call that getter "getDPI",  
and hence make the slot-declaration be something like:

    (slot resolution 'Resolution in dots per inch' Number Player  
getDPI Player setResolution:)

and you can then simply define Player >> getDPI as:

Player >> getDPI
    ^ self getResolution

We have a number of examples in the image where the same visible slot  
name represents different underlying selectors, with different help  
messages, when associated with different kinds of morphs.  I don't  
think we have any examples where the same visible slot name is  
associated with data of two different *types* (and arguably that's not  
good practice...) but as long as you make the getters distinct in the  
slot declarations, I don't see any reason why it shouldn't work.


   -- Scott

More information about the Etoys mailing list