Custom number parser

[GoogleCodeExporter]

Parse expressions with custom variables and functions.

Original issue reported on code.google.com by milo...@gmail.com on 26 Nov 2011 at 3:17

• Blocking: #1, #1

[GoogleCodeExporter]

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?

Original comment by milo...@gmail.com on 26 Nov 2011 at 3:26

[GoogleCodeExporter]

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

Original comment by mrpuzz...@gmail.com on 26 Nov 2011 at 4:34

[GoogleCodeExporter]

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 ]

Original comment by milo...@gmail.com on 26 Nov 2011 at 4:49

[GoogleCodeExporter]

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

Original comment by mrpuzz...@gmail.com on 26 Nov 2011 at 4:54

[GoogleCodeExporter]

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.

Original comment by James.P...@gmail.com on 26 Nov 2011 at 7:07

[GoogleCodeExporter]

Original comment by milo...@gmail.com on 3 Dec 2011 at 4:44

[GoogleCodeExporter]

Original comment by milo...@gmail.com on 14 Nov 2012 at 4:17

• Now blocking: #1, #1

[GoogleCodeExporter]

Original comment by milo...@gmail.com on 20 Jun 2014 at 8:27

• Changed state: WontFix