Alternative PR to address uniqueness ordering and properties, introducing handle(bson)

[hhaensel]

This PR is in most parts identical to #151 but it makes DEFAULT_DICT_TYPE a true constant and converts all property calls to bson.handle to calls like handle(bson), where bson is any variable of type BSON.
This is inspired by #146.

[ancapdev]

It might be better to separate these changes in two PRs, but some comments here.

Property based data access

The getproperty() change is API breaking, which I think deserves more careful consideration. At minimum it needs to be released as a major vesion change. I'd also suggest either the API is changed to this new model, or it's not, not some halfway point where we pretend to support handle access by property name and it works conditional on the data held in the document.

Dict type

Have you considered surfacing this as OrderedDict(::BSON), where the materialization into the dictionary is applied with this dictionary type recursively? This could be implemented as a package extension, rather than a hard dependency. Maybe the dictionary type could be a parameter to BSONIterator as well, would seem natural and ergonomic.

[hhaensel]

Thanks for answering:
I am well aware of the implications of the proposed changes and the PRs were rather meant to showcase their usefulness/feasibility than to be a ready solution.
My first PR was a copy of my personal extension that was sufficient for my use case. When I thought for a bit longer I disliked my halfway approach and therefore submitted #152 .
I could, indeed, imagine that all the proposed changes go into a version 0.11.0. It would be a similar move as JSON did when they published v1.0, where they replaced Dict with the ordered JSON.Object. People who want to make use of the new notations would need to update and make sure that they adapt their programs with respect to the handle field.
I am open for any solution and I could prepare 2 or 3 different PRs depending on your preference. Below I list the changes that we may want to distribute to different PRs:

• introduce getindex with a second optional index that contains a Dict type that is used recursively
• introduce getindex with a Symbol key, also with an optional second index. This method makes sure to read the last entry
• introduce merge!
• introduce getproperty (setproperty! is not critical as that can be solved by type dispatch)

Leaving both getindex methods with String key and Symbol key could be interesting. People who are sure that they don't overwrite or call merge! explicitly can benefit from less iteration, if String keys always returns the first entry.

Questions to be answered_

• Should getpropert use the Symbol key or the String key method?
• Should OrderedDict be the default type for all getindex methods?

Concerning your question with BSONIterator, you're probably right, but I'm at the beginning of using the package and didn't have the need to use BSONIterator yet.

Concerning your proposal of OrderedDict(::BSON) is indeed tempting, why not defining
OrderedDict(::BSON; recursive::Bool = true)

EDIT:

One more question:
Chosing a version that adds an extension MongocOrderedCollectionsExt is perhaps a good interim solution. The only problem is that Mongoc currently supports julia 1.6 while package extensions are supported from version 1.9 onwards. How would we deal with that? There is the possibility of adding julia 1.6-1.8 support via the package Requires.jl (as I have done for Stipple and some other packages from the GenieFramework), but that adds about the same amount of code as OrderedCollections would...
But if I would add such an extension, should I then default the output of getindex(::BSON, ::Symbol) to OrderedDict?