If a message is not in the canonical form of known-method-name arguments, then it will be parsed for Syntactic Sugar. You can provide your own methods for doing this, (see parseMessage, sugar and keySugar for details).
By default, only key sugar is implemented. This means that a message in the form
will be rewritten as
by the parser, and
will be rewrittan as
In general, you can implement any sort of syntactic sugar you like. Typically, it is used to make your messages simpler, shorter and easier to type (and read). You can also use it to change the name of your method. Syntactic sugar allows you to parse the entire message in any way you like, and rewrite it completely.
An alternative way to change the name of your method is to use isMethod to point to an executable with a different name.
Simplicity, ease of use, ease of typing, readability. Use of familiar paradigms, and so on. For example, you could implement
Okay, I really meant hiding side effects, but I didn't want to say that out loud :)
Let's say you have an offsider that has a whole lot of keys with values. For every key, you also have an attachment, with the same name, that holds the same value but in a different form (for example as html). You can implement this by providing a method called sugar (to override the default method).
sugar will trap any message of the form:
and call a method which also modifies the value of the corresponding attachment.
You have thus ensured the integrity of the data, without making life difficult for the user.
Once you depart from the canonical form of a method, you can no longer be absolutely certain what any particular message should mean. Even the default syntactic sugar has this problem.
A very good example is the Weave. Any item in the database can have methods, keys and navigation keys. Syntactic sugar is provided for keys and navigation keys.
If you now send a message like:
to a random item on the database, then it typically won't have anything that corresponds to that name (blah). The problem is - is blah an unknown method, an unknown key or an unknown navigation key? How should the item respond to this message?
This is also potentially a problem for anyone reading the code. If you are not careful in naming your keys, navigation keys and methods, then a message like
might be very difficult to decipher. How much of it is syntactic sugar? Which are methods and which are navigation keys? Users of the Weave technology will be very much aware of how complex messages full of syntactic sugar can easily arise
If you have designed your message API well, then the meaning will be obvious, irrespective of the implementation details. With offsiders it is good to put at least as much thought into the message design as you put into the design of the software and data components. Often, it is a good idea to design your messages first.
Syntactic sugar will neccessarily run slower. Whether this is a problem will not be known until you have implemented the code and tested it. I strongly advise against premature optimisation. If syntactic sugar looks like a good idea, then it probably is. If you later discover that it really is too slow, then you can usually provide explicit methods that replicate the syntactic sugar. (For example, if myOffsider criticalKey: value causes speed issues, then you can implement a method called criticalKey:. This will short-circuit the message parsing so that the syntactic sugar is not even considered.)
(20100210 09:40:36) This page was produced using rsml. Source file was syntacticSugar