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