ObjectSavingFramework – Supporting Lists

One of the biggest missing features of the current Object Saving Framework is that there is no native support for lists. There is a way to bypass the issue, but it’s a nasty one. In this blog post I first go into depth about how to bypass the issue, this will make it clear that native support is essential, and finally I will discuss some issues with supporting it.

With the current API all elements are saved/retrieved based on name. Which means that each element must have a unique name (within the scope of the object), and that for retrieval this names needs to be known. With a list of dynamic size this introduces an additional problem, how do you know how many elements have been saved?

To save a list with the limitations of the current API I found the following solution:

  1. The list is saved as an object.
  2. The list has a field named ‘size’, which saves the amount of elements.
  3. Each element of the list is saved using the same name as the list itself appended with the index.

Doing this would result in the following conversion from list to JSON:

vector<std::string&gt; names = {'John', 'Jack', 'Joe'}
"names": {
    "size": "3",
    "names-0": "John",
    "names-1": "Jack",
    "names-2": "Joe"
}

The converted JSON file makes the constraint very visible. The desired JSON file would look more like the following:

"names": [
    "John",
    "Jack",
    "Joe"
}

The fact that all of this logic is imposed on the client is nasty. A simple, fast solution would be to move this logic into the Object Saving Framework, but even then we can all agree that this is not the nicest format we have seen. Ideally you would have an API that allows to add/get elements one by one such that the client code can just iterate over it. There is however a problem when trying to do this.

As I said before the current API requires a name for each object or field, but an element of a list does not have a name, and we don’t want to force the client to provide a meaningless name. But how do we let the client add an element without a name, but at the same time still be strict about the naming for objects or fields?

Starting or ending a list can be done just as with an object, but adding elements requires knowledge of the current object you are adding elements to. While the DataGatherer could keep track of this, it is not a very clean API because we can’t prevent the client from calling it by accident resulting in a crash. Another issue with a list is that is can either be a value, an object or another list. This would cause even more special methods to be added resulting in more confusion for the user.

Since the API can not easily be extended without mutilating it, I have decided to implement this feature with a complete re-design of the API, which has to be done no matter what.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.