I've been thinking, and while I like the current parser, it does assume a lot. I think a step back is needed that allows for a more powerful and flexible parser for situations where the current parser is ill suited. A SAX-like parser would provide these advantages, and I think JSON.net highlights it perfectly. There, so far, is no pressing need for this parser and if implemented, this parser would only complement the current one and not replace it. Here is an example to better illustrate functionality.
The actual parsing logic in the parser would be very small with a large number of extension methods. Core parsing methods would return nullable or null instead of throwing exceptions, as exceptions are not flexible and are expensive. Let the client decide what they want to do. Parsing an object would go as follows:
// Prior content [...]
while (reader.Read())
{
if (reader.Token == PropertyName)
{
switch (reader.Value)
{
case "player": Player = reader.ExpectString(); break;
case "date": Date = reader.ExpectQuotedDate(); break;
case "rivals": Rivals = reader.ExpectQuotedStringList(); break;
// [...]
}
}
}
// The client can write some pretty cool extension methods
// (Or these can just be included)
public static string ExpectString(this ParadoxSaxReader reader)
{
var value = reader.Value;
var result = reader.ReadString();
if (result == null)
// A simple error message... can be more complex with line number, etc
throw new ApplicationException("Expected string after " + value);
return result;
}
public static DateTime ExpectQuotedDate(this ParadoxSaxReader reader)
{
var value = reader.Value;
DateTime? result = reader.ReadDate();
if (result == null || !reader.Quoted)
throw new ApplicationException("Expected quoted date after " + value);
return result.Value;
}
public static IList<string> ExpectQuotedStringList(this ParadoxSaxReader reader)
{
var value = reader.Value;
if (!reader.Read() || reader.Token != StartObject)
throw new ApplicationException(/* */);
IList<string> result = new List<string>();
while (reader.Read() && reader.Token != EndObject)
result.Add(reader.ExpectQuotedString());
if (reader.Token != EndObject)
throw new ApplicationException(/* */);
return result;
}
public static string ExpectQuotedString(this ParadoxSaxReader reader)
{
var value = reader.Value;
var result = reader.ExpectString();
if (!reader.Quoted)
throw new ApplicationException(/* */);
return result;
}
Just some thoughts I was having. I don't think it matters if one parser is faster than the other, they both have distinct benefits.
I've been thinking, and while I like the current parser, it does assume a lot. I think a step back is needed that allows for a more powerful and flexible parser for situations where the current parser is ill suited. A SAX-like parser would provide these advantages, and I think JSON.net highlights it perfectly. There, so far, is no pressing need for this parser and if implemented, this parser would only complement the current one and not replace it. Here is an example to better illustrate functionality.
The actual parsing logic in the parser would be very small with a large number of extension methods. Core parsing methods would return nullable or null instead of throwing exceptions, as exceptions are not flexible and are expensive. Let the client decide what they want to do. Parsing an object would go as follows:
Just some thoughts I was having. I don't think it matters if one parser is faster than the other, they both have distinct benefits.