Member selection and undefined vs null

[head.in.the.box]

The current tests return null when you access a property that does not
exist

SELECT { x:[abc.name,abc,abc.xyz], y:10 } FROM abc;
.result {"x":["abc",{"name":"abc"},null],"y":10}

However, in JavaScript abc.xyz would return undefined, and some Json
implementations in .NET throw in this case.

Anyway, if UnQL values are Json, then I guess we should follw the
JavaScript semantics with all the ugliness of undefined and null and
== and === etc. Or not?

Erik

[p...@pi.net]

> Anyway, if UnQL values are Json, then I guess we should follw the
> JavaScript semantics with all the ugliness of undefined and null and
> == and === etc. Or not?

But isn't this exactly what would happen under JS semantics (i.e.
documents
are JSON strings, which get converted to JS values and are operated
upon,
and then get converted back to a JSON string document)?

The transient JS value would indeed contain 'undefined', but once that
value
gets JSON.stringified back to an UnQL document that undefined is
converted
to null. Note that if the undefined was not an array element, but a
plain
object element, then it would get ommitted from the JSON string
altogether.

Converting undefined array elements to null is quite core to JSON,
imho, and
JSON stringify should only throw an exception when asked to serialise
a
circular structure. Would you know the rationale / use case for
some .NET
implementations to throw when encountering an 'undefined' value?

Paul