I agree. Lets use _sn then.
=(get|set)_property=get_property and set_property are useful for 'fake' properties, like private fields in the underlying C structures that aren't installed properties, but should be serialised. If I only had to worry about GObject properties, serialization for me would be much easier. :D
=*_sn=Regarding using the full word serializable in the method names, that isn't so bad in Vala, but in C it looks a bit ridiculous, having the word serializable appear twice. In C, it's obvious from the fact that it's a gxml_serializable_ function that you're not calling the object class's list_properties or find_property. If a programmer is making use of serialization, in either C or Vala, I think
* it will be obvious that _sn stands for "serialization" after the first time they read the docs* it will be syntactically cleaner; I abhor needlessly long function names* using _sn will be consistent, and make it obvious that _sn functions are part of the Serializable set.
* they differ less from their analogues in GObject and GObjectClass, maintaining the cognitive connection, while remaining distinct=change wanted=So (get|set)_property are actually useful, and I'd like to keep them.
I also really want the _sn naming convention for the reasons above.On Wed, Apr 2, 2014 at 4:44 PM, Daniel Espinosa <esodan gmail com> wrote:
We need to consider that just in Vala like in C, the method name, must allow the programmer to understand its purpose.In C: gxml_serializable_list_serializable_properties ()GLib.ParamSpec[] list_serializable_properties ();produce: a test_get_name () and test_set_name (const gchar* name) avoiding redundancy, leaving GObject Introspection bindings to use GObject default get_property () and set_property () methods.public string name { get; set; }class Test : Objectbecause they are already defined in GObject class and instead use get_PROPERTY and set_PROPERTY as defined by Vala when a GObject property is declared:set_property ()If continue to reduce redundancy we can drop:get_property ()
{
}
If you need a standarized way to transform strings to properties you can use Serializable.transform_* methods taking GValue and strings to transfrom to/from.We just need a way to list just the properties to be serialized, thats way I've used:
Even find_serializable_property () could be avoided in Serializable and leave as GObject define it. If you want to find a serializable property you can use list_serializable_properties() and iterate around.
In SerializableObjectModel, we just iterate over list_serializable_properties() on serialization and pass the current Node to deserialize from to all serializable properties (from the above) and try to deserialize to a known property; some times from a Attr, some time using Element child Nodes, depending on the property object type.
2014-04-02 10:24 GMT-06:00 Richard Schwarting <richard schwarting ca>:
If we go with the _sn convention, then the analogy to the existing GObjectClass and GObject methods also remains clearer (which is what json-glib seemed to intend).Amusingly, with json-glib's serialization implementation, because it was targetting C, they didn't have those conflicts that we ran into. (They had json_serializable_get_property, and we had gxml_serializable_get_property in C, but then we also had Serializable.get_property () in C; oh my).The sn is supposed to reflect that it's serialization specific (s*n -> sn). I think it will help keep which methods belong to it tidy, and avoid accidental conflicts in Vala.get_property_snlist_properties_snfind_property_snSerializable.find_property_spec () list_serializable_properties () get_property_name () set_property_name ():
I previously suggested a different naming convention, something like
set_property_sn
Can we go with those name changes?
On Wed, Apr 2, 2014 at 12:11 PM, Richard Schwarting <richard schwarting ca> wrote:
Question about the Element. Previously, you would get a GXmlDocument, and then you would return a GXmlNode representing the property you just serialized, and then GXml.Serialization.serialize_object () would attach it as a child to the larger GXmlNode that represented your whole object. So, would the Element instead be pre-created to hold your property's XML? Or would the passed Element represent the whole object's XML (so the implementer would just make a new node (as before) for the property, and then attach it as a child themselves to the Element?)Probably for reasons similar to those discussed in the e-mail about deserialize_property (removing unnecessary redundancy?).GXml.Node? Serializable.serialize_property (Element element, GLib.ParamSpec prop)GXml.Node? Serializable.serialize_property (string property_name, GLib.ParamSpec spec, GXml.Document doc)Serializable.serialize_property ():You changed it from
to
I kind of prefer just giving serialize_property () the GXmlDocument and letting the caller attach the returned GXmlNode (representing the property) to the object itself. Did you require/want greater flexibility than that? I like how it creates a predictable structure, but perhaps that is an obstacle for you in using the serialized XML to present richer program data.
On Wed, Apr 2, 2014 at 12:03 PM, Richard Schwarting <richard schwarting ca> wrote:
I'm not really attached to this "optimisation", of having redundant parametres, though. I'm happy to just go with your version, and we could change things before 1.0 if we find it necessary later.That way, for programming efficiency in Vala, the implementer could still effectively ignore the redundant parameters. However, for people serializing/deserializing a lot of stuff, they could avoid using new memory on each property and avoid additional cycles per property.bool Serializable.deserializable_property (Node property_node, string? prop_name = null, ParamSpec? spec = null);Perhaps we could do something in vala likeI think part of the reason that json-glib had these redundant pieces of data was for efficiency. If you're deserializing a lot of properties from a lot of nodes, the calls to first extract the name and then obtain the spec when necessary can add up in both lines of code and number of calls. Being able to just pass those in saves on that.I'm guessing you removed the two initial parametres because they are in some ways redundant. The property name is probably (but not necessarily) stored in the property_node, right? So you can extract the prop_name from there, and you can find the spec yourself from the object's class.bool Serializable.deserialize_property (Node property_node);I see that your API for it isbool Serializable.deserialize_property (string prop_name, ParamSpec spec, Node property_node)Serializable.deserialize_property ():The API formerly was:
On Wed, Apr 2, 2014 at 11:45 AM, Richard Schwarting <richard schwarting ca> wrote:
at some point, if we determine a way to define GObject classes arbitrarily and dynamically though. :DorSo, my question about the return value stands, whether it should be returning a GXmlNode at all.Serializable.deserialize () (part 2):
I'm dense. I suppose it's supposed to give someone control over how the XML is deserialized into an object outside of just individual properties.
The purpose of having a .deserialize () should just be clear in the documentation, that it's used in the deserialization process.
It makes me think that it might be worth adding a method on
GObject *gxml_node_deserialize ();
GObject *gxml_document_deserialize ();
On Wed, Apr 2, 2014 at 11:39 AM, Richard Schwarting <richard schwarting ca> wrote:
Why does .deserialize () return another GXmlNode? Is it supposed to be just a reference to the existing GXmlNode that was passed in?.deserialize () as an object method kind of makes sense if you're going to use g_object_new () to create an empty object (whose type implements Serializable) and then have it fill itself in from a GXmlNode's content. Is that what you hope to see this used for?Serializable.deserialize ():Does this make sense to have as an object method? In theory, it's taking XML (an GXmlNode) and parsing it to create a new GObject. It makes it seem like it's better as a class method (like the current gxml_serialization_deserialize_object ()).
On Wed, Apr 2, 2014 at 11:33 AM, Richard Schwarting <richard schwarting ca> wrote:
Serializable.serialize():What's better?
1. GXmlNode serialize (GXmlNode node)
- you're already using it
- the implementation has access to the underlying owner_document (should specify in documentation that a user should use that, and not naively create a new GXmlDocument, to create any new nodes)
- downside is that the caller has to identify a node in an advance to serialize it into (though they could probably just use doc.document_element if they're lazy)
2. GXmlNode serialize (GXmlDocument doc)
- Jgs is already using it- advantage over passing a node is that the caller doesn't have to prepare a Node to store it in, in advance, they can just pass a document and have the serialization implementation automagically append it to the document root (or wherever implemented methods decide to)
- I like this one best
3. GXmlNode serialize ()- can't unless we drastically change the memory model (since this way, we wouldn't have a direct reference to the Document and it would be freed and our returned GXmlNode would be invalid
4. GXmlDocument serialize ()- not so hot, since we wouldn't have a direct reference to the GXmlNode for the XML we just serialised into, we'd have to search the document for it.
- benefit is that the caller wouldn't need to create/manage a GXmlDocument before serializingOn Wed, Apr 2, 2014 at 11:24 AM, Richard Schwarting <richard schwarting ca> wrote:My idea is reflected in the new branch "serialization_isolation" where I'm basically moving serialization implementations into their own submodules/directories. Just for the general idea. One issue with SerializableJson is that it needed to 'implement' features it doesn't want. It wants to be dead simple and as automatic as possible. So instead I'm going to mostly adapt the original Serialization to go under its own submodule, jgs, with a bare Serializable interface under just gxml/ (as reflected in the previous e-mail).I'm going to ask some questions about the interface shortly. If you disagree with my suggestion to structure your serialization work under its own subdirectory, the interface questions will still be applicable to even if it's kept in the main one.
On Wed, Apr 2, 2014 at 10:20 AM, Richard Schwarting <richard schwarting ca> wrote:
Does having Xom as a submodule completely under your control sound good? If so, if you can make that change and merge it, it'll make reviewing individual pieces a lot easier.You've written a lot more code than I have over the past 8 months especially. Largely I've been unavailable due to school and work and budo, but it's stupid of me to prevent you from advancing GXml somewhere useful. You're also a good programmer, so you should be free to commit changes at this point, I think. I mostly want to keep the core of GXml small, keeping most implementation details in libxml2 for now.If you'd like this, I'm fine with trusting you to also push changes to gxml/xom/ whenever you like. If you need to make changes to gxml/* stuff outside of gxml/xom/, I'd also be fine with a short review window (1 week?) after which if I don't even respond, you can just push things anyway.gxml/xom/XomSerializable.valagxml/jgs/JgsSerializable.vala /* for json-glib-style serialization */gxml/Serializable.valaWe could let the common serializable interface be defined at something likeAnd a namespace likegxml/So, if you wanted to use XML Object Model as the name of your submodule (or whatever you like), we could have directories like:When I said complicated, it's in part because the original goal in adding Serialization was to keep it Simple and Automatic. You've recently added some wonderful, useful code for serializing different Gee structures. My hope was rather instead of handling class-specific code to handle such things, to work towards a way to better automatically handle them. (Some of them would require new functionality in either gir or vala to be able to access private fields that weren't properties, which is ugh and a long way off.)Would you actually be amenable to including serialization under a nested namespace, in its own directory, as a submodule?I used the word unnecessary above, because just to serialize a GObject into XML on disk and back, a lot of the features are unnecessary, but I shouldn't use that word, as you obviously have use cases that are valid, that you're making use of. You mentioned how your serialization API could be used to actually save application data in existing formats, I believe. (Like AppData.) Whenever I look at it, I've foolishly been trying to minimise the amount of "feature creep", to avoid including a bunch of code that ultimately gets rarely used. If it's a submodule, I don't mind it having a life of its own. (E.g. make and commit whatever changes to the submodule you want!)
That helps alleviate the issue of its size a bit. GXml was originally just a wrapper around libxml2 that provided a DOM API. With Serialization not being its main purpose, your Serialization code in your branch is about ~1/3 the entire code base. If it's its own submodule, then I don't think it matters how big it gets.
gxml/xom/
GXml.Xom
On Tue, Apr 1, 2014 at 7:02 PM, Richard Schwarting <richard schwarting ca> wrote:
I'm still working on the last review you requested. Basically I want all the serialization merged, but not exactly as is. It's just gotten really big and hard to get done in a single sitting.
On Tue, Apr 1, 2014 at 6:49 PM, Daniel Espinosa <esodan gmail com> wrote:Thanks for your response.
El abr 1, 2014 2:35 p.m., "Richard Schwarting" <richard schwarting ca> escribió:
>
> No.
>
> It is large, complicated, and makes unnecessary changes.I think we need more than just say that.
> It also consumes all my free time that I have to work on GXml trying to restart reviews on
I haven't seen you working on GXml in months.
> it since earlier ones never had their concerns addressed.b
>
>Again please!!! Send to this list your concerns, even the ones at early commits I can explain you what and why each.
I've been waiting for a while with no comment.
All my work always have been public at early stages.
I think we can't hold my work indefinitely.
> On Tue, Apr 1, 2014 at 3:00 PM, Daniel Espinosa <esodan gmail com> wrote:
>>
>> I've found serialization branch ready to merge.
>>
>> * Fixed and stabilized Serialization framework
>> * Fixed and running win32/win64 compilation
>>
>> Task TODO:
>>
>> * Fix Unit Test in order to get no error/warning messages
>> * Clean up Serialization class in order to support default and user defined
>> serialization method for GObjects
>>
>>
>> --
>> Trabajar, la mejor arma para tu superación
>> "de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE)
>>
>> _______________________________________________
>> gxml-list mailing list
>> gxml-list gnome org
>> https://mail.gnome.org/mailman/listinfo/gxml-list
>>
>
--
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE)