Custom number parser

[miloyip]

From milo...@gmail.com on November 26, 2011 23:17:34

Parse expressions with custom variables and functions.

Original issue: http://code.google.com/p/rapidjson/issues/detail?id=3

[miloyip]

From milo...@gmail.com on November 26, 2011 07:26:55

This should be a good idea. But is it still need to validate the JSON number format? If it need to support more flexible format, how to determine ending of a number?

I have two ideas of API in my mind:

1. Generates a Handler::Number(const Ch* str, SizeType length) event. This requires Reader knows the termination of the number type.
2. Generates a Handler::Number(InputStream& stream) event. Then user can do what ever he wants to parse the number from the input stream.

Any comment?

[miloyip]

From mrpuzz...@gmail.com on November 26, 2011 08:34:58

termination of the number - comma or end of section. For example we have:
{
"xOffset": 250 + parent.with/2,
"yOffset": 0.4 + sin(2)
}

[miloyip]

From milo...@gmail.com on November 26, 2011 08:49:41

I just wondering, in this particular case, will it be better to just use string instead:

{
"xOffset": "250 + parent.with/2",
"yOffset": "0.4 + sin(2)"
}

Your application can permit "xOffset" be either a number or string. When it was parsed as a string after JSON parsing, your application can parse it as an expression or whatever you need.

To support your idea directly, the parser can just copy the characters from input stream until it encounters ",", "]", or "}". But I can also think of some cases the "expression" may fool the parser. For example, if the expression support indexing with []. E.g.
[ 250 + children["a"].width ]

[miloyip]

From mrpuzz...@gmail.com on November 26, 2011 08:54:10

Sure, we can use strings for such cases. This is the simplest solution.

[miloyip]

From James.P...@gmail.com on November 26, 2011 11:07:32

We wouldn't really know if we're able to evaluate the expression during parse(). We would be using JSON as a model format to build the object tree and then evaluating the expressions. That gives us access to things like 'parent.width.'

If you do write up the Handler::Number() to parse the stream, you still don't have access to any DOM structure, just the character stream. That means the custom Handler::Number would only be able to use custom variables that were loaded in your expression parser and nothing from the JSON DOM tree.

You could add a post processing step, but then why not let that responsibility fall on the end user?

---

As for delimiting the expression that may contain {} or what ever, use a stack or a counter to ++increment on opening braces and --decrement on closing. If the counter falls below zero then the section has closed. Always stop parsing on commas.

[miloyip]

From milo...@gmail.com on December 02, 2011 20:44:28

Blocking: 1

[miloyip]

From milo...@gmail.com on November 13, 2012 20:17:34

Blocking: -rapidjson:1 rapidjson:1 rapidjson:1