One of the primary benefits and peculiarities of the Smalltalk family's style of method syntax is that it provides an opportunity to name one's protocols using something resembling a phrase. Usually, it is recommended to re-use protocols whenever describing similar behaviors, as an aid to the user's memory in matching functionality to a name to call; in some exceptional situations, different protocols are helpful when there is more than one desired algorithm or behavior to provide for a kind of object. Here are some general practices which have been brought forward from years of Smalltalk practice.
Attributes are perhaps the simplest to name of all, in that they are generally nouns or noun phrases of some sort, whether used as direct slots or methods which calculate a property dynamically.
Methods which test for some fact or property about a single object are generally given a ``whether''-style phrase. For example, myCar isRed answers whether one's car is red. Slate offers an additional idiom over this particular style, in that myCar color is: Red is also possible, since is: looks at both the subject and the object of the query. The only remaining obstacle is whether the conceived subject can stand on its own as a named concept; if there are multiple perspectives in normal use, the language can support a certain amount of ambiguity using subjective overrides, but there are limits to this.
While the method clone is the core of building new objects in Slate, rather than instantiating a class, there is still the need to provide and use an idiom for delivering optional attributes and varying semantics of creation to one's new objects. Generally, these methods should start with new- as a prefix to help the reader and code user to know that the original object will not be modified, and that the result is a new, separate individual. These methods are usually methods with keywords, with each of the keywords describing each option. If the keyword literally names an attribute, the optional-keyword facility is ideal, but if providing a grammatical phrase using prepositions, it is preferable to create a full keyword method.
The most interesting protocols are akin to commands, where one addresses the objects in question with a phrase that suggests performing some action. This should usually have one key verb for each major component of the action (there is usually just one action per method, but select:thenCollect:, for example, performs two), and prepositions or conjunctions to relate the verbs and nouns.
There is a particular idiom of languages without multiple dispatch to add the noun (or type) name of an argument to the name of a function involving it. Slate makes this unnecessary and an obstacle to polymorphism, since the type of an argument can be specified in a dispatch as needed. Of course, nouns still sometimes have a useful place in a method name, when the noun is not a formal type, but an informal role or usage name.
These are perhaps the most controversial of any programming language's protocols. In the Smalltalk family of syntax, there are no precedence orderings between operators of different names, so the issues with those do not arise. However, it is very tempting for the library author to re-use mathematical symbols for her own domain, to allow her users to have a convenient abbreviation for common operations. While this benefits the writer of code which uses her library, there are domains and situations that punish the reader of the code that results.
For example, mathematical addition and multiplication symbols, ``+''
and ``*'', are generally associative and commutative.
That is, repeated calls to these should be able to re-order their
arguments arbitrarily and achieve the same result. For example,
.
However, string concatenation (as an example) is not commutative;
we cannot re-order the arguments and expect the same result, i.e.
"gold"+"fish"="goldfish"
, whereas "fish"+"gold"="fishgold"
. Because concatenation is associative, however, we can re-use
the punctuation style of the semi-colon ``;'' and achieve
intuitive results. This general style of reasoning should be applied
wherever this type of operator name re-use could arise.