Example:
#define first Martin
#define second Carlberg
var first##second = 13;
Compiles to:
var MartinCarlberg = 13;
Example 2:
#define _function(inline) function inline { return _##inline; }
#define _CGPointMake(x_, y_) { x:x_, y:y_ }
_function(CGPointMake(x, y))
Compiles to:
function CGPointMake (x, y) {
return {x: x, y: y};
}
When a statement ends without a semicolon and a Send message expression is on the next line it was wrongly parsed as a single Send message expression. It should be an ExpressionStatement with a Send message expression inside.
This change makes it possible to @deref any expression, such as a conditional expression, as long as the expression doesn't have side effects.
The reason not to allow dereferencing of expressions with side effects is that we might need to evaluate the expression twice in certain uses of deref, which is not obvious when you look at the deref operator in plain code.
Array literals look like `@[a, b, c]`.
This syntax is supported for completeness and source compatibility, but are not terribly useful since standard JavaScript arrays are toll-free bridged to CPArray.
Array literals could be handy if you're replacing CPArray with your own implementation.
Without this fix the new compiler would treat IBOutlet as the type and expect the next token to be the ivar name.
This fix make the new compiler treat IBOutlet the same as @outlet.
With the new compiler, messages such as `[a in:b]` could not be sent, the "in:" parameter throwing an unexpected token error. This was true both if "in" was the first argument or any of the subsequent parameters (such as in `[a something:X in:Y]`).