summaryrefslogtreecommitdiff
path: root/json-glib/json-object.c
Commit message (Collapse)AuthorAgeFilesLines
* Update the JsonObject documentationEmmanuele Bassi2021-06-101-83/+86
|
* docs: Initial, rough port away from gtk-docEmmanuele Bassi2021-06-081-120/+119
| | | | | | | | | | Drop `SECTION` blurbs. Use gi-docgen syntax for internal links. Use summary lines for gi-docgen indices. Use Markdown syntax for code fragments.
* Assert that foreach_member() won't mutate the objectEmmanuele Bassi2020-08-241-0/+5
| | | | | | | We document that it's not safe, but we kind of rely on GHashTable to do that for us. Instead, let's use the newly added age field to protect against accidental mutations during iteration, just like we do for the iterator API.
* Document the iteration order for foreach_member()Emmanuele Bassi2020-08-241-0/+3
| | | | | The iteration order is the insertion order, and has been for a long time.
* Add ordered iterator for JsonObjectEmmanuele Bassi2020-08-241-2/+111
| | | | | | | | | The current iterator API does not guarantee the iteration order, as it's based off of the hash table iterator. JsonObject, though, can guarantee the iteration order—we do that for json_object_foreach_member(). Instead of changing the behaviour of json_object_iter_next(), we can add API to initialize and iterate a JsonObjectIter in insertion order.
* docs: Clarify some expections of the json_object_get_*_member APIsDebarshi Ray2018-03-141-14/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | It is an error to use the following with a missing member: • json_object_get_int_member • json_object_get_double_member • json_object_get_boolean_member • json_object_get_null_member • json_object_get_string_member • json_object_get_array_member • json_object_get_object_member Doing so will lead to CRITICALs like these: Json-CRITICAL **: json_object_get_string_member: assertion 'node != NULL' failed Instead one of these should be used to determine the existence of the member: • json_object_get_member • json_object_has_member Or, when available, one can use the corresponding json_object_get_<type>_member_with_default. https://gitlab.gnome.org/GNOME/json-glib/issues/24
* Add with_default() variant for JsonObject gettersEmmanuele Bassi2017-11-141-74/+131
| | | | | | | | | | | | | | | When using the typed getters for JsonObject, the existing API will automatically fail if the member requested is not present. This is generally good practice, because JSON data typically does not have a schema, and thus is has to be validated "on the go"; a JSON object member that contains `null`, or `0`, or `false`, is indistinguishable from a JSON object member that does not exist, so we cannot simply return a scalar value and be done with it. We can provide an escape hatch, though, for the crowd writing parsers for JSON data; by using Python as the model, we can add methods that take a default value as a parameter, and return it as a fallback value if the requested object member does not exist, or if it's set to `null`.
* core: Avoid json_object_get_members()Garrett Regier2017-06-161-0/+9
| | | | | | | Use JsonObject's private members_ordered GQueue instead. This avoids a g_list_copy(). https://bugzilla.gnome.org/show_bug.cgi?id=773504
* object: Use a GQueue for members_orderedGarrett Regier2017-06-161-17/+10
| | | | | | | | This makes the list always ordered and removes the g_list_reverse() in json_object_get_members(). https://bugzilla.gnome.org/show_bug.cgi?id=773504
* docs: Clarify when NULL might be returnedMatthew Leeds2017-03-181-13/+14
| | | | | | | | | If a JsonObject has no members, json_object_get_members() and json_object_get_values() will return NULL, so this commit makes that behavior clear in the docs. It also adds the (nullable) annotation in a few places in the same file. https://bugzilla.gnome.org/show_bug.cgi?id=769206
* docs: Fix the Since tagsEmmanuele Bassi2016-03-011-6/+6
| | | | The newly added API is available since 1.2.
* core: Add JSON node, object, array hashesPhilip Withnall2016-03-011-1/+98
| | | | | | | | | | | | | | | | | | | Now that these objects can be marked as immutable, it is possible to calculate and cache hash values for each of them. This allows efficient hash-based deduplication of large numbers of JSON nodes, as needed by Walbottle for JSON test vector generation. To complement the new hash functions, each of JsonNode, JsonValue, JsonObject and JsonArray also now have an equal() comparison method. This compares them structurally and recursively, using the definition of equality from the JSON Schema specification, which seems as good as any other. http://json-schema.org/latest/json-schema-core.html#anchor9 https://bugzilla.gnome.org/show_bug.cgi?id=756121 Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
* node: Add json_node_ref() and json_node_unref()Philip Withnall2016-03-011-2/+2
| | | | | | | | | | | | | | Add reference counting semantics to JsonNode, in addition to the existing init/unset and alloc/free semantics. json_node_free() must only be used with nodes allocated using json_node_alloc(). json_node_unref() may be used with all nodes (if correctly paired; it may be paired with json_node_alloc()). It is not valid to call json_node_free() on a node whose reference count is not 1. https://bugzilla.gnome.org/show_bug.cgi?id=756121
* core: Add immutability support to core objectsPhilip Withnall2016-03-011-0/+51
| | | | | | | | | | | Add an immutable mode to JsonNode, JsonObject, JsonArray and JsonValue. This is an optional mode which objects enter by calling json_*_seal(). It is a one-way transition, which means that we can build and manipulate objects as much as desired, before sealing them and enjoying the benefits of immutable objects: no need to take copies when handling them, persistent hash values (still to be implemented). https://bugzilla.gnome.org/show_bug.cgi?id=756121
* core: Remove atomic operations for reference countingPhilip Withnall2016-01-281-2/+2
| | | | They are not needed — json-glib is not at all thread safe.
* object: Add JsonObjectIter to ease iteration over JsonObject membersPhilip Withnall2015-10-061-0/+71
| | | | | | | | | | This is a stack-allocated iterator object similar to GHashTableIter which allows allocation-free iteration over the members in a JsonObject. It differs from json_object_foreach_member() in the order in which it iterates — for JsonObjectIter the order is undefined. https://bugzilla.gnome.org/show_bug.cgi?id=755509
* lib: Trivial documentation clarificationsPhilip Withnall2015-09-011-2/+4
| | | | | | | Clarify the documentation for json_node_set_object() and json_object_get_array_member(). https://bugzilla.gnome.org/show_bug.cgi?id=754384
* Remove conditional inclusion of config.hEmmanuele Bassi2014-03-181-3/+0
| | | | All the platforms and build system we support have a config.h header.
* docs: Port to MarkDownEmmanuele Bassi2014-03-181-4/+5
| | | | | Drop the DocBook documentation, and move everything to the MarkDown format used by modern gtk-doc.
* Add missing annotationsEmmanuele Bassi2014-02-141-3/+3
| | | | | JsonNode, JsonObject, and JsonArray have various constructors, so we need to annotate them.
* Use the new typed JsonNode initializersEmmanuele Bassi2012-10-271-30/+18
| | | | | The typed setters in JsonArray and JsonObject should use the JsonNode typed initializers.
* Consolidate null handling in JsonArray and JsonObjectEmmanuele Bassi2012-10-271-1/+10
| | | | | | A null value is not only valid for JSON_NODE_NULL nodes, but also for JSON_NODE_ARRAY and JSON_NODE_OBJECT nodes that do not have a JsonArray or a JsonObject set.
* docs: Fix typo in JsonObject's descriptionEmmanuele Bassi2011-10-171-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=660893
* Remove G_CONST_RETURN usageEmmanuele Bassi2011-06-091-1/+1
| | | | | | | | See GLib bug: https://bugzilla.gnome.org/show_bug.cgi?id=644611 The macro is going to be deprecated soon.
* Use the new atomic functions for refcountingEmmanuele Bassi2011-06-031-7/+2
| | | | | The newly added g_atomic_int_dec_and_test() simplified the logic for unreffing Object and Array.
* object: Use g_list_find_custom()Emmanuele Bassi2011-04-081-10/+3
| | | | Instead of manual iteration, let's use the function GList provides us.
* Fix introspection annotationsEmmanuele Bassi2011-02-151-2/+2
|
* object: Replace the name pointer in the members listEmmanuele Bassi2011-02-151-0/+21
| | | | | | | | | | | | | | When calling g_hash_table_replace() we also free the string holding the member name. This means that the const gchar* pointer we store inside the list of ordered member names now points to garbage - so if somebody tries to iterate over the members list it will get random values instead of a valid C string. Since we guaranteed insertion order, if we replace the contents of a JsonObject member we need to find the right pointer and replace it: just removing and prepending won't do. https://bugzilla.gnome.org/show_bug.cgi?id=642383
* object: Do some more validation in set_member()Emmanuele Bassi2011-01-101-0/+10
| | | | Check if we're setting the same node, to avoid a needless replace.
* Add missing introspection annotations.Luca Bruno2011-01-101-4/+4
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=638932
* Use G_DEFINE_BOXED_TYPE()Emmanuele Bassi2010-10-191-12/+1
|
* Add introspection annotationsEmmanuele Bassi2010-09-251-2/+2
|
* Allow NULL as a value for strings, arrays and objectsEmmanuele Bassi2010-06-161-9/+36
| | | | | We should not warn when asking for a string, array or object if the contents were 'null'.
* Initialize every member of JsonObject on constructionEmmanuele Bassi2010-01-101-0/+1
| | | | | We create JsonObject structures using g_slice_new(), so we need to initialize every member of the structure ourselves.
* Update Introspection annotationsEmmanuele Bassi2009-11-121-12/+13
| | | | | | | • Fix the transfer rules for JsonNode, JsonObject and JsonArray getters. • Annotate the methods returning lists
* object: Return values list in insertion orderEmmanuele Bassi2009-10-301-48/+7
| | | | | | | | | Since we return the member names in insertion order, we should also return the member values in the same order. This also allows us to get rid of the (yucky) internal copies of g_hash_table_get_keys() and g_hash_table_get_values(), since we use the hash table only for storage and lookup purposes.
* object: Guarantee insertion orderEmmanuele Bassi2009-10-261-32/+35
| | | | | | | | | | When iterating over the members of a JsonObject, or when retrieving the list of members, the insertion order should be preserved by the JsonObject. This is simply implemented by keeping a mirror list of the member names. Apparently, though JSON does not guarantee any ordering, it is somewhat expected by JSON (and ECMAScript) users.
* [docs] Remove note about normalization of member namesEmmanuele Bassi2009-08-161-5/+1
| | | | | The normalization of member names inside JsonObject was removed by commit 8a7e0f381dc7e49745680df92ebb428f18bf4832.
* Do not sanitize the object member's nameEmmanuele Bassi2009-08-121-29/+6
| | | | | | | | | | | JsonObject sanitizes the name of the member to replace all characters defined by G_STR_DELIMITERS with '_'. This is absolutely brain damaged, since a member name can be any valid JSON string. Obviously, if a member name maps to a GObject property is entirely up to the GObject code to decide whether to sanitize the member name or not.
* Auto-promote integer types to G_TYPE_INT64Emmanuele Bassi2009-08-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The JSON RFC does not specify the size of the integer type, thus implicitly falling back to machine-size. This would all be fine and dandy if some demented Web Developer (and I use the term "developer" *very much* loosely) did not decide to use integers to store unique identifiers for objects; obviously, you can't have more than 2^32-1 status messages in a database with millions of users who update their status multiple times per day. Right, Twitter? Anyway, some languages do a type auto-promotion from Integer to Long, thus pushing the limit of allowed positive values -- until the next integer overflow, that is. C, and GLib, do not do that transparently for us so we need to: - always use gint64 when parsing a JSON data stream using JsonScanner - move all the Node, Object and Array APIs to gint64 - auto-promote G_TYPE_INT to G_TYPE_INT64 when setting a GValue manually - auto-promote and auto-demote G_TYPE_INT properties when (de)serializing GObjects. The GLib types used internally by JSON-GLib are, thus: integer -> G_TYPE_INT64 boolean -> G_TYPE_BOOLEAN float -> G_TYPE_DOUBLE string -> G_TYPE_STRING
* [docs] Fix typo in JsonObject::set_object_member()Emmanuele Bassi2009-06-251-1/+1
| | | | The passed value is a pointer to a JsonObject, not to a JsonArray.
* Use JSON_NODE_OBJECT, not JSON_NODE_ARRAY when creating the node in ↵Rodrigo Moya2009-06-241-1/+1
| | | | | | json_object_set_object_member Reviewed by Emmanuele Bassi
* Fix license and copyright noticesEmmanuele Bassi2009-06-091-3/+6
| | | | | | | | THere is no such thing as the "Lesser General Public License version 2": the LGPL v2 is the "Library GPL", and has been superceded by v2.1 with the new "Lesser GPL" name. Also, the copyright is now Intel Corp.
* [node] Make JsonNode completely privateEmmanuele Bassi2009-06-091-8/+1
| | | | | | | | | | The JsonNode structure has always been meant to be completely opaque; we indirectly exposed the :type member, but only for access through the JSON_NODE_TYPE() macro. Since that macro has become a proxy for the json_node_get_node_type() function we can safely move everything into a private, uninstalled header file and let JsonNode be completely opaque to the developer.
* Add JsonObject iteration functionEmmanuele Bassi2009-05-161-0/+55
| | | | | The json_object_foreach_member() function iterates over a JsonObject data type.
* Deprecate add_member() and add set_member() and friendsEmmanuele Bassi2009-04-171-16/+473
| | | | | | | | | | | | | | | | | | | The add_member() method of JsonObject has wee bit weird semantics: if the member to be added already exists it prints a scary warning and returns - and yet it calls g_hash_table_replace() internally as if it overwrites the member. So, instead of changing semantics midway we can: - add a json_object_set_member() which adds a new member and overwrites existing members - deprecate json_object_add_member() While we're at it, we can add convenience wrappers for set_member() and get_member() that don't require us toying with nodes; luckily, since the amount of valid types we can add to a JsonObject is limited, this does not lead to a combinatorial API explosion.
* Use the normalized member name in has_memberEmmanuele Bassi2008-01-281-1/+1
| | | | | The json_object_has_member() used the passed in member name, instead of the correctly normalized one.
* Wrap config.h include with conditionalsEmmanuele Bassi2007-12-251-0/+2
| | | | | Including the autotools generated config.h should always be conditional on the HAVE_CONFIG_H definitions.
* Add API to retrieve copies of the nodes inside objects and arraysEmmanuele Bassi2007-11-211-0/+29
| | | | | | Getting copies of the nodes might work better for high level languages binding the JSON-GLib API, because they can manage the lifetime of the returned values using their own rules.
* Add a method for getting all the nodes from a JsonObjectEmmanuele Bassi2007-10-161-0/+41
| | | | | To map json_array_get_elements(), a json_object_get_values() method has been added which returns the list of JsonNodes contained by a JsonObject.
View Lorry Controller Status