[Etoys] type clash in viewer slots
scott.wallace at squeakland.org
Fri Jun 6 18:49:30 EDT 2008
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
>>> 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.
More information about the Etoys