System.Int64 and System.Decimal is not treated as "number" type when returning values from .NET to V8, which System.Int32, System.Float and System.Double currently is.
public int a { get { return 1; } }
public long b { get { return 1; } }
public float c { get { return 1.0f; } }
public double d { get { return 1.0; } }
public decimal e { get { return 1.0M; } }
Properties [a], [c] and [d] will have typeof() set as "number" while [b] and [e] will have typeof() set as "object" (native .NET object); valueOf() will fail for [b] and [e]. Methods requiring System.Int64 and System.Decimal as arguments will have a argument mismatch when calling from V8.
Perhaps implicit support for both types, V8->.NET and .NET->V8.
One situation is where file offsets is required. Using Int32 will remove support for large files while Int64 will cause casting/conversion to be required at all methods using the type.
public int a { get { return 1; } }
public long b { get { return 1; } }
public float c { get { return 1.0f; } }
public double d { get { return 1.0; } }
public decimal e { get { return 1.0M; } }
Properties [a], [c] and [d] will have typeof() set as "number" while [b] and [e] will have typeof() set as "object" (native .NET object); valueOf() will fail for [b] and [e]. Methods requiring System.Int64 and System.Decimal as arguments will have a argument mismatch when calling from V8.
Perhaps implicit support for both types, V8->.NET and .NET->V8.
One situation is where file offsets is required. Using Int32 will remove support for large files while Int64 will cause casting/conversion to be required at all methods using the type.
