[Etoys] type clash in viewer slots

[K. K. Subramaniam]

On Friday 06 Jun 2008 2:13:05 pm Scott Wallace wrote:
> 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:)
This is what I did. But that still leaves the possibility of conflict open. 
The viewer code doesn't report the conflict but simply picks up the first 
type in the list. The blowup happens only when the affected morph is opened.

> 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...)
A static type spec seems like a regressive move. Any specific reasons?

Subbu