[Etoys] type clash in viewer slots

[Scott Wallace]

On Jun 6, 2008, at 4:23 AM, Bert Freudenberg wrote:
> On 06.06.2008, at 12:52, K. K. Subramaniam wrote:
>
>>> all methods are in the Player, and Player is the only type of
>>> object in the Etoys philosophy. Only depending on which costume the
>>> player currently wears are some methods hidden in the viewer.
>> Should'nt an error be reported if there are two identical getter/
>> setter methods, then?

Yes... it would be nice, whenever the etoy vocabulary is rebuilt,  
automatically to look for potential conflicts.

In the meantime, there's a minor tool available in the image that we  
use internally when extending the etoy vocabulary to check for  
conflicts:  evaluating "ScriptingSystem  
searchForSlotProtocolConflicts" while you have a Transcript open  
produces a printout to the Transcript that is useful in identifying  
conflicts, if you know what you're doing.  The printout shows all  
multiple definitions for a single slot-name -- you can then  
investigate any that seem worth pursuing by first selecting a help- 
message, then using alt-shift-e to find the method(s) in which the  
corresponding entries are defined.  The majority of entries shown in  
the printout do not represent errors, since distinct getters can  
freely be associated with distinct slot-definitions (as we've  
discussed in another branch of this thread today,) but what you see is  
a superset of possible problem areas.  With a little effort, this  
method could be extended to give more useful information (and to  
eliminate less-than-useful info,) and perhaps a UI to the improved  
tool from the authoring-tools menu might be appropriate.

To paraphrase Bert's observation, "being extended by users outside the  
core developer team was not on the requirements list."

There's clear room for improvement in this regard.


>>> So it is not a bug but a conscious design decision. Extensibility  
>>> was
>>> not high on the requirements list.
>> The category definitions seemed to be designed for extensibility. The
>> following spec would have been simpler:
>>   ( slot name description type getter setter categorylist)
>
> Well, I'll leave that to Scott to answer.

Agreed, that would have been simpler, and also less of an invitation  
to the creation of slot definitions that inadvertently conflict.


Cheers,

   -- Scott