Month: November 2016

Now you can convert your GObject classes in XML nodes. This is, you can read and write XML trees directly to object classes’ properties, from basic types to complex like object properties, representing XML element’s attributes, to other child elements, while you can use collection of child nodes.

This has been easiest to implement than GXml.SerializableObjectModel, which requires you to read an XML tree and then translate to your object properties. This should be slower than new GOM implementation included in this release.

Next, should be to test it in a real project like GSVG and make some performance tests.

These are old results of GDocument vs TwDocument, used by SerializableObjectModel, to serialize and deserialize large files (3.1MB). In future articles, hope to attach this GomDocument performance and resources comparations with all existing implementations in GXml.

Today I’ve finished to push last implementation for GXml GOM, to allow write, to XML:

• Object Properties, as child nodes of current class
• Object Properties, as element’s attributes
• Object Collection Properties, referencing XML child nodes

Object Properties

In GXml GOM, any GomElement is an XML Element node. If it has GomElement as properties, they will be added as child nodes.

Object Properties as Attributes

If your GObject class implements GomProperty interface, and is a property in your object, it will be translated to an Element attributes with a name and a text value.

For simple types, this means you can control if an attribute is written or not, depending if it is not null. Standard properties, not GObject classes implementing GomProperty, they will be always written with its default value. This is, for example, a boolean will always use false by default.

Using GomProperty, you can define default actions when a property is omitted in XML file.

Complex Object Properties

Some times, your string representation of attributes include more information than just values, like units. In GSVG, you have an attribute like: length=”3.8 cm“. You can implement an object with properties for each value component like:

public class Length : Object {

public double value { get; set; }

public UnitsEnum units { get; set; }

}

With GXml GOM, is now possible to implement W3C SVG 1.1 specification interfaces, most objects will be complex properties to be translated to Element’s attributes. Once you implement a way to parse a string representation to your object’s properties and back, you can have GomProperty objects in your GomElement to be de/serialized to attributes.

Collections

GomElement objects are containers, by definition, in DOM4. It can have child nodes of different local names and namespaces.

Once you have a set of different nodes, may you want classify them by their node’s names and for, for example, its id attribute.

GXml GOM, have added a set of basic collection classes, implementing GomCollection interface. ArrayList and HashMap, are classes you can use to access child nodes. All references are to child node’s indexes, no copy or ref-counted objects.

Examples

If you want to see how implement different kind of classes and properties, you can checkout GXml repository Unit Tests.

Now with all in place for DOM4, GXmlGom is getting support to derive classes from GXml.GomElement, making easy to serialize your GObject classes to XML.

Now you just need to prefix your GObject’s property nicks with “::” and it will be used as XML Element attribute. Now Gom have support for strings, integers, unsigned integers, double and enumerations properties types.

I you have this class:

  public class Taxes : GomElement {
[Description (nick=”::monthRate“)]
public double month_rate { get; set; }
[Description (nick=”::TaxFree“)]
public bool tax_free { get; set; }
[Description (nick=”::Month“)]
public Month month { get; set; }
construct {
_local_name = “Taxes”;
}
public string to_string () {
return (_document as GomDocument).to_string ();
}
public enum Month {
JANUARY,
FEBRUARY
}

You can use:

var t = new Taxes ();

printf (t.to_string ());

and you’ll get:

<Taxes monthRate=”16.5” Month=”february” TaxFree=”true“/>

Next steps will be to implement reading XML documents back to your GObject’s properties.

You will find more “examples” and advances at GXml repository.

This post is based on my experience on not just using but creating and maintaining Vala libraries.

Rust is on the horizon and have voices to use it instead Vala. For Vala, we can say, is true to be niche oriented language, because it just create GObject based applications and libraries. For Rust, it has a more general purpose, with save concurrency and save programming: true again.

I have downloaded Rust to start using it, because seems to be very convenient for C development replacement, specially may be suitable to replace old libxml2 library, hopping some some have started to write an XML parser and writer, I can re-use in my own projects.

After taking a time to check at Rust documentation and write a post about GObject and Rust, I would like to share my thoughts about Vala and Rust.

Vala have a very specific target: GObject. We can use Vala to create GObject classes and define API interfaces using GInterface, but in a sugar and very productive syntax. Doing Object Oriented Programming using Vala and GObject is easy and natural.

I’ve managed to get W3C set of API interfaces based on specifications for DOM and SVG, because Vala provides a kindly close interface definition syntax to the ones from W3C. Implement them have been a matter of, you know, work. W3C interfaces are really complex in a way of their relations ships and dependencies, which should be very difficult to implement if doing in C and GObject/GInterface. This is not false for Rust, because it doesn’t have a GObject/GInterface mechanism, at least not jet.

In my opinion, Rust should develop its own, more powerful and secure, implementation of GObject/GInterface, based in their own internal types, like Traits.

I don’t know if Rust is planning to provide an Object Oriented like mechanisms, like GObject/GInteface, with properties, signals, introspection and inheritance, but is very convenient for other languages and implementing Object Oriented API, like the ones from W3C.

While I write this article, I’m studding Rust, to find equivalences and possibilities, thinking on how to port my work to Rust if possible. At least, for now, I can’t, but I have been just little time, I need to follow its development and road map.

Vala development can be used by Rust applications and libraries, because is C and GObject, and because it produce GIR files to create bindings easily for Rust, along with other languages.

If GObject is your choice to write your next library or Application, I can recommend to use Vala: you’ll get a very productive syntax and a easy bindable API.

No, I’ve don’t want to stop my self to Vala. Just is very convenient to produce GObject based libraries, use any C based library too, and is really productive. My work on GXml, can’t be just dropped and its capabilities to Serialize GObject classes, by introspection of its properties, are very useful and productive. I’ll share more in these later.

First all, I’m not a Rust programmer, this is just a point of view of my first impressions about Rust, from documentation of it, and how I see it to use with GObject.

From documentation Rust provides a low level and high level API to access common operations. Provides a set of assumptions to help its great features like automatic memory management, secure and concurrent data access. On high level side, Rust provides a rich set of common collection, iterators, tuples and others.

For GObject interoperability, there is a project , and this too, I found to allow you to use GObject based libraries in Rust, while they depends on other project, or directly on GObject Introspection generated XML files to introspect these C libraries.

I don’t see a GObject equivalent, not jet at least, into Rust. From GNOME developers site, I found an introduction to GObject:

• A generic type system to register arbitrary single-inherited flat and deep derived types as well as interfaces for structured types. It takes care of creation, initialization and memory management of the assorted object and class structures, maintains parent/child relationships and deals with dynamic implementations of such types. That is, their type specific implementations are relocatable/unloadable during runtime.

• A collection of fundamental type implementations, such as integers, doubles, enums and structured types, to name a few.

• A sample fundamental type implementation to base object hierarchies upon – the GObject fundamental type.

• A signal system that allows very flexible user customization of virtual/overridable object methods and can serve as a powerful notification mechanism.

• An extensible parameter/value system, supporting all the provided fundamental types that can be used to generically handle object properties or otherwise parameterized types.

One of the most powerful features on GObject is C, but at the same time it its weakest one, because GObject through GObject Introspection makes easy to create bindings to any languages, including Rust. But is hard to write code for GObject classes and interfaces. GObject provides an Object Oriented programing paradigm to C.

I don’t think any one is thinking to rewrite GObject based libraries to Rust, because you can. Then lets put this option aside for a moment.

While Rust have great features, I would like to find a way to write a Rust library and share it through GObject Introspection GIR, making it available to other languages at day 0. Just remember GObject Introspection, is better suitable for GObject based libraries.

I don’t find in Rust a direct GInterface equivalent, no classes, no object properties and signals, no error reporting equivalent to GError. All of them are getting in, by bindings from GLib, GObject and GIO libraries, written in C, using GIR. I don’t think any one will re-write that libraries to Rust.

GObject bindings to Rust are not stable jet and may mature enough in a few years, depending on demand, resources and their use in new written code.

My personal conclusion

• GNOME will relay on GObject for next 5 to 10 years.
• GObject will be improved and maintained in same period.
• GObject Introspection will be a vehicle to easy access C libraries from other languages, including Rust.
• Rust will grow and hope they’ll add object oriented mechanisms equivalent to GObject/GInterface, in order to provide equivalent more secure and concurrent safe API to create new libraries.
• C language, will be here for next 20 years, but may gradually delegated to raw operations.