[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.
Cheers,
-- Scott
More information about the Etoys
mailing list