Hi,
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
On 06.06.2008, at 07:55, K. K. Subramaniam wrote:
Hi,
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?
Because the Etoys object model has no classes. It uses a "fat" object model, 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.
So it is not a bug but a conscious design decision. Extensibility was not high on the requirements list.
- Bert -
On Friday 06 Jun 2008 2:03:35 pm Bert Freudenberg wrote:
Because the Etoys object model has no classes. It uses a "fat" object model,
You mean a "flat" object model?
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?
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)
Subbu
On 06.06.2008, at 12:52, K. K. Subramaniam wrote:
On Friday 06 Jun 2008 2:03:35 pm Bert Freudenberg wrote:
Because the Etoys object model has no classes. It uses a "fat" object model,
You mean a "flat" object model?
Flattening makes the object fat, too :)
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?
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.
- Bert -
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
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
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
On Jun 6, 2008, at 4:20 AM, K. K. Subramaniam wrote:
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.
The "getter" is the *sixth* item in the viewer spec, "getDPI", not the second item, "resolution". The thing that needs to be unique is that sixth item. If you make that unique, you'll find that the types do not stomp on each other and that everything works as you'd hope.
Please see the attached fileout for a fully-worked example where the same slot-name is made to be associated with different types in different morphs. In this example, a numeric slot "xxx" is added to the digital clock (ClockMorph) and a color-valued slot of the same name, "xxx", is added to TextMorph. Both are visible in the "basic" categories of their respective morphs.
-- Scott
On Jun 6, 2008, at 1:56 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.
The "getter" is the *sixth* item in the viewer spec, "getDPI", not the second item, "resolution". The thing that needs to be unique is that sixth item. If you make that unique, you'll find that the types do not stomp on each other and that everything works as you'd hope.
A minor, though obvious, correction. I omitted the "readWrite' item...
The slot-spec item above should read:
(slot resolution 'Resolution in dots per inch' Number readWrite Player getDPI Player setResolution:)
... so the getter is *seventh* item in the slot spec, not the sixth item.
Sorry...
-- Scott
etoys-dev@lists.squeakfoundation.org