Add support for the final parameter to a variadic function to be a slice.
Add support for conversion of slice parameters.
Expand numeric conversion support to include all int and uint types as souce types. This allows the result of bitwise calculations (int32) to be passed in as parameters.
Javascript uses int64 (literals) and float64 (default) representations for numbers so to allow easy use of go funcs apply automatic conversion for function parameters where it is safe to do so.
Add support for go funcs which return multiple values by returning them as an array.
In the future this can be used along side destructuring assignment to provide a nice way to deal with multiple value returns e.g.
[val, err] = MyGoFunc()
Previously, it was a publically accessible but invalid value (valueEmpty).
* Deprecate internal use of UndefinedValue(), NullValue(), FalseValue(), TrueValue()
* Guard against Empty, Result, Reference values from escaping the package
This fixes#68
Some changes over the original patch, removing references to utf8string.String:
* (better) This removes a dependency on a non-standard (though solid) package
* (better) utf8string.String has mutable parts
* (worse) utf8string.String has a smarter consecutive access approach (by
remembering where the last access was)
* (?) _stringWide allocates a []rune if charAt or charCodeAt access is needed (though
it will only do this once for the string object)
* Streamline what we get from "otto/parser"
* Get rid of some "otto/parser" cruft
* FunctionExpression => FunctionLiteral
* The debugger statement (debugger) should do nothing (not panic)
* Fix aspects of function expression call evaluation
* The "reflect" package is willing to expose unexported fields in structs (a little suprising).
* Skip unexported fields when enumerating or trying to access (pretend they don't exist).
* Allow structs that implement json.Marshaler to work as expected in a JSON.stringify call.
If we let the runtime try to access unexported fields, it'll cause a panic.
This fixes#64
* Faster, more straightforward, etc.
* More advanced object literals (get ..., set ...)
* More tests using JavaScript from the wild (http://cdnjs.com/)
Basically, the Go runtime sees the gelcap shell of the exception,
which dissolves (payload is set to nil) once we catch the error.
This prevents the Go runtime from hanging onto a heavy object for the
panic log (or whatever it is doing with the panic value).
This fixes#59
