summaryrefslogtreecommitdiff
path: root/json-glib/json-object.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Add a note in the JsonObject documentation for the member name normalizationEmmanuele Bassi2007-10-161-1/+5
|
* Normalize every member name before using itEmmanuele Bassi2007-10-161-5/+26
| | | | | | | | | Every member name is stored inside the internal hash table of JsonObject using a normalized string: every delimiter found matching G_STR_DELIMITERS is automatically transformed in an underscore ('_'). This means that "member-name" and "member_name" are completely equivalent for a JsonObject.
* Provide an internal g_hash_table_get_keys() and bump down GLib dependencyEmmanuele Bassi2007-10-151-0/+25
| | | | | | | Even though GLib 2.14 is now available, many systems still come out with GLib 2.12. Since we are using just a single 2.14 function for retrieving the members from a JsonObject, we can provide an internal version of that function and hideit behind a pre-processor macro.
* Add API for removing nodes from arrays and objectsEmmanuele Bassi2007-10-151-0/+17
| | | | | | | Write and document json_object_remove_member() and json_array_remove_element() which can be used to remove a JsonNode from a JsonObject or a JsonArray respectively. This way, the JsonObject and JsonArray are API-complete and the object model can be manipulated in code.
* Fix documentation about the ownership of the nodesEmmanuele Bassi2007-10-071-5/+8
| | | | | When adding a JsonNode to a JsonObject or a JsonArray, the containers take ownership of the node.
* Implement the GType functions for JsonObject and JsonArrayEmmanuele Bassi2007-10-051-0/+13
| | | | | | | | | | The type functions for the JsonObject and JsonArray types were declared, albeit with the wrong return value, but not implemented. This commit fixed the return value and implements them. JsonObject and JsonArray are boxed types because we don't need them to be GObjects (no signals, no inheritance and their implementation must be completely opaque for the developer).
* Document the new public functionsEmmanuele Bassi2007-10-011-0/+15
| | | | | Now that we moved the constructors and setters for the JSON data types into the public symbols we need to document them to get back to 100% doc coverage.
* Move data types ctors and setters into the public headersEmmanuele Bassi2007-10-011-1/+0
| | | | | | | Now that we are providing a generator class we need to provide the constructors and setters for JsonNode, JsonObject and JsonArray. This also means that the json-private.h header is now useless, so we can remove it from the build and repository.
* Add licensing informations to the source codeEmmanuele Bassi2007-10-011-4/+30
|
* Add JsonNode, a generic container for JSON typesEmmanuele Bassi2007-10-011-32/+12
| | | | | | | | | | | | | | | | | This huge commit removes JsonData and adds JsonNode, the generic container for fundamental and complex data types extracted from a JSON stream. The contents of a JsonNode can be extracted from it in form of a GValue for fundamental types (integers, floats, strings, booleans) or in form of JsonObject and JsonArray objects. JsonObject and JsonArray now accept JsonNodes instead of GValues. The JsonParser object builds the data model tree when parsing a JSON stream; the tree can be recursed by getting the root node and walking it using the GValue API for the fundamental types and the objects/arrays API for complex types. The API has been updated and the tests now recurse through the generated data model tree.
* Initial import of JSON-GLibEmmanuele Bassi2007-09-201-0/+201
JSON-GLib is a JSON parser library written with GLib and GObject. JSON is the JavaScript Object Notation, and it's used to define objects and object hierarchies in a human-readable way.
View Lorry Controller Status