Selectors : When and Why

[Nostalgic]

I'm curious about selectors and how important they are. I'm actually more concerned with why I would use one. I know selectors are important to the internal functioning of how the SCI VM takes care of things.

I see from a brief blurb in the SCI Studio help that I can use a selector (via #) to reference a method or property indirectly. But I don't see why I would want to.

The comments in the example given say that "there are some times that this method is necessary" but it doesn't say what those times might be, even in general. I did look in the template game and I do see that the # notation is used in a few limited cases, but I'm not ferreting out the overall benefit or when this is necessary as opposed to just optional.

Anyone have any ideas on this one?

[lskovlun]

A selector is just a number that represents a property or method uniquely. It can be considered an odd cross between procedure pointers and interfaces. One peculiarity of the SCI object model is that an object is characterized not by its class but by the methods that class implements. In the Ruby community, this is called duck typing - "If it #walks like a Duck and it #quacks like a Duck, then it must be a Duck". It has multiple uses. Say you have a List object that contains a number of other objects (buttons in the case of my Keypad class). You want to be able to show/hide them all at once. Now, in the KeypadButton class we implement show and hide methods. We can now ask the List object to call these methods on all the contained objects by doing:

Code: [Select]

(self:eachElementDo(#show))
Another trick that would be possible to use in SCI (but was never exploited in Sierra games) is to do selectable callbacks. In the template game, if you start a MoveTo object going, it calls the #cue method when the actor reaches his destination (the state machine paradigm). This could be generalized to call any method the programmer likes.

[Nostalgic]

Thank you for this information. It is very helpful. If I can let me try to make sure I understand.

Say you have a List object that contains a number of other objects (buttons in the case of my Keypad class). You want to be able to show/hide them all at once. Now, in the KeypadButton class we implement show and hide methods. We can now ask the List object to call these methods on all the contained objects by doing:

Code: [Select]

(self:eachElementDo(#show))


In the Collect class (from script.999, "Obj"), I see there are lines like this:

Code: [Select]

self:eachElementDo(#showSelf)
self:eachElementDo(#dispose)

If I understand things, this is basically doing what you said: it's allowing you to reference the individual objects to call their showSelf and dispose methods. But the reason you do it this way is because you may not know what objects are actually going to be in the "collection" (i.e., instances of the Collect class). Not only that, but it lets you not worry about what type of object is part of the "collection" because it's allowing to treat the objects as the same sort of thing for the time being: i.e., as a thing that has a dispose or a showSelf method.

Is that in any way accurate?

[lskovlun]

That is quite true, yes. It is also used in the Print routine, by the way,
where it works sort of like "keyword arguments" in Python. But that is not part of the raison d