Re: [Vala] Help me find the right Vala idiom
- From: Chris Elston <celston katalix com>
- To: vala-list gnome org
- Subject: Re: [Vala] Help me find the right Vala idiom
- Date: Tue, 06 Mar 2012 10:44:15 +0000
Thanks to both Mark and Andrea for taking the time to look at this for
Mark's solution is good because it looks to me like pretty clean OO
without using GObject introspection. I'm not sure on the cost of
wrapping each fundamental type in a parse class though. How much memory
does each of those wrapping class instances take up when my config class
might have hundreds of them?
I like Andreas solution too, particularly because it separates the
business of parsing the data from the target class to be instantiated
with the data. It also seems like it would scale better because the
fundamental types in ConfigData aren't wrapped in another class.
Some quick profiling shows that Andrea's solution gives a binary about
2.5 times bigger and about half as fast as the C (for 100 iterations).
Although Andrea's solution is also doing more error checking than my
quick and dirty example. Is this fairly typical of Vala code. Can anyone
comment on how much of that is down to Vala and how much is down to
GObject? i.e.: if I were to write equivalent GObject C, would I get
similar performance and size to the compiled Vala code?
On Mon, 2012-03-05 at 21:50 +0100, Andrea Del Signore wrote:
On Mon, 2012-03-05 at 14:12 +0000, Chris Elston wrote:
I have a pattern I commonly use in C which I've so far failed to
translate to an equivalent Vala or indeed OO equivalent. I was hoping
that those more used to thinking in such terms would be able to point me
in the right direction.
Even if I don't think this method is what are you looking for, because
is not a strict "equivalent", I attach a vala program that use some
GObject-foo for filling the config properties.
The nice thing about this method is the "no-config" API, on the other
side we have to pay some cost in performance and flexibility :)
Suggestions gratefully received!
] [Thread Prev