This method answers a SequenceableCollection of symbols that represents method selectors within the application that should always be included when the application is packaged. The packager uses this method to determine the list of selectors that the application should always include even if there is no explicit reference to them in the code being packaged
This method should return a list of method names that are not directly referenced by your application, but which you want to include in the packaged image. You might use this method if your code uses perform: to send messages at runtime. For example, suppose a class implements seven methods, one for each day of the week, and you call these methods based on the following code:
The packager assumes that any symbols it finds in the source code of applications are references to methods. The packager does this to minimize problems caused by the use of perform:, as noted above. When the packager looks for errors, it may produce a list of warnings related to symbols that are used only to describe state and are not used as selectors.
To eliminate these errors, your application can return a list of known symbols. The application should provide a class method named packagerKnownSymbols that returns a list of these symbols. This method answers an array of symbols used as atoms within the application . This instructs the packager to filter these symbols from any check done to verify that each known symbol has at least one implementor.
You can use atoms instead of symbols for the purpose of identifying state. For example, use ##mode instead of #mode. Atoms are instances of EsAtom. The packager does not interpret atoms as selectors, so the use of atoms reduces the need for packagerKnownSymbols
For example, suppose you want to create, from an ASCII file, EmployeeRecord (an abstract class) that may be SalariedEmployeeRecord or WeeklyEmployeeRecord (concrete subclasses). You can read an identifier from the file and then broadcast a message to subclasses of the abstract class to determine which kind of object is in the file at this point. For example:
If your application uses this technique or a similar one, it should implement a class method named packagerIncludeClassNames, which returns a list of classes to include in the packaged image. In the above example, the method may look like the following:
Sometimes a class may override the doesNotUnderstand: method and then redispatch a different method. For example, you might have a set of selectors (#sequentialFile, #keyedFile, and #directFile) that are sent to some central point, trapped through doesNotUnderstand:, then redispatched as #sequentialFileFor:, #keyedFileFor:, and #directFileFor: to an appropriate service by code such as the following:
If your application uses this coding style, you should define the method packagerTranslateSelectors in your application class. This method should return a dictionary with the keys being the original selectors and the values being the redispatched selectors. The packager will then include in the packaged image methods referenced by both the key and value of each entry. In the above example, the method would look like this:
This method allows an application to provide a list of selectors to which references can be ignored. This method is functionally identical to packagerKnownSymbols, however, methods identified with packagerIgnoreSelectors are not made visible to the user.
