copying of values in constructors

[Benito van der Zander]

Hi,
I just noticed that object and array constructor are supposed to create copies of the values passed to them.
Would it not be more useful, if they just keep the same value? (so far I thought, they did that like a normal map)

Making a copy is
a) slower than keeping a reference
b) loses information like the document and parents of the node

E.g. having 2 as result of

let $a := <a><b>1</b><c>2</c></a>
return {"x": $a/b}("x")/../c/text()

seems to be nicer

Benito

[Ghislain Fourny]

Hi Benito,

We considered this decision point during JSONiq design. There are several reasons for this decision that I can give you background about.

1. XQuery/JSONiq supports trees, not graphs (like Java or C++ would) -- at least not directly (but it does in the form of RDF triples, for example).
2. If you work against JSON data stores (like we do on 28.io), it makes sense that parents "own" their children values. References would get lost upon persisting unless you add the necessary machinery.
3. An implementation is free to optimize and not do copying if it is able to infer that this is transparent to the user (i.e., no identity exposure, etc).

XQuery 3.1's maps might behave as you expect though.

I hope this helps?

Kind regards,
Ghislain

> --
> You received this message because you are subscribed to the Google Groups "JSONiq" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jsoniq+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Till Westmann]

Hi Benito,

I would like to add to Ghislain's 2nd point.

In addition to the problem losing references when storing the data one also gets the problem of losing references when exchanging the data between systems. While the storage problem can be addressed with some effort (if the storage is owned by the JSONiq implementation), it is usually impossible to address it when other systems are involved. And since JSON (and XML) are mainly used as data-interchage formats, I think that this is an important aspect for the language design (unfortunately XQuery is a little lax on this aspect ...).

Just my 2c,
Till

[Benito van der Zander]

Hi,

1. XQuery/JSONiq supports trees, not graphs (like Java or C++ would) -- at least not directly (but it does in the form of RDF triples, for example).

I do not see how that is related.

Perhaps non copying constructors could be used for graphs, but that would be nicer than not having graphs?

2. If you work against JSON data stores (like we do on 28.io), it makes sense that parents "own" their children values. References would get lost upon persisting unless you add the necessary machinery.

Well, I only ever use it to return multiple sequence from functions.

XQuery 3.1's maps might behave as you expect though.

In fact, I have implemented JSONiq, because I though then I do not need to write a separate map implementation as well

 

Bye,
Benito