If you have been using Gee for a while, you have noticed it produce a lot of warnings not at Vala compilation but at C compilation time.
GXml is using Gee for a while too and we are facing the same. I have some proprietary applications using Gee too.
Recently I started to search the source of these warnings. I found valac producing C code with simple cast to parent but not the current class, this is:
_tmp25_ = gee_abstract_collection_get_size ((GeeCollection*) _tmp24_);
This function requires to cast to GeeAbstractCollection, this is why we see some of these warnings.
In order to reduce this warnings I started to use “as” operator. When transformed in C, it first check if the object to cast is the type of required one, if not it just pass a NULL pointer, on success it just cast.
Now in my internal code, and soon on GXml, I have used “as” operator, to reduce this C warnings and producing less stress. But at the same time, when you have a C warning, you should fix it, in order to reduce the risk of improper behavior or crash. Now most of you using Gee or GXml, have lot of warnings and you have chosen to ignore them, because is not produced by your code; may in some times is the case, but when you see lot of them, you prefer to ignore all if valac no warns you.
I’m sure we need to change some Vala code at Gee source code level, but that is another history and I’ll go for them, when have time enough; if you can help, please file bugs with patchs and I can help you to push to Gee or GXml, making Vala programming a pleasure as is today.
EDIT:
Ok, it is unexpected, I have to admit, but Gee has a clean compilation without any warning.
At the same time, while changing my own code, found changing simple properties like size to (object as Gee.Map).size is enough to remove annoying warnings, but to get objects on foreach statement you should change from:
foreach (MyObject o in collection_object.values)
to
foreach (MyObject o in (collection_object as Gee.Map<string,CollectionObject>).values)
requiring more work at writing your code time.
Conclusion: This is a valac bug, producing C code without correct casts.
