Re: [Vala] Port Tomboy?

[Levi Bard <taktaktaktaktaktaktaktaktaktak gmail com>]

> > What is the current state of interaction between Vala and Mono? I mean,
> > would it be possible to take a useful Mono library, rewrite it in Vala,
> > and make the Mono programs pretty much transparently use the rewrite
> > instead of the original library?

Since Vala libraries provide a C api, they would all be easily
accessible from e.g. C#.
In fact, an early iteration of the Vala addin for MonoDevelop was
directly using libvala to
derive context-sensitive completion data.

> There are tools to automatically create a managed wrapper for
> GObject-based library, so yes, it would be possible. Although I'm not
> sure how eager would Mono programmers be to use such wrapped version.
> Wrapped native code is generally slower and more difficult to work
> with then a pure CIL implementation. The library in question would be
> more likely to exist in two separately maintained versions.

Many applications that run on Mono already use managed wrappers on
native gobject libraries, a prime example being gtk+.
Debian users, `apt-cache rdepends libgtk2.0-cil` to see a few.
The gobject api generation works similarly to the vapi generation for
Vala, in that it mainly Just Works and tends to require a few tweaks
to fix things that don't get automagicked correctly or to take
advantage of language features.

> > If that is the case, I'd call such a rewrite a gain for the GNOME platform
> > as a whole, since it would make a previously Mono-only library available to
> > all the languages in the platform.

I agree that creating a general-purpose library that doesn't expose a
C api is annoying and moderately selfish. Coincidentally (considering
the context of this thread), I see that actually happening much more
often with python and ruby than I do with mono.

Given that such a library exists, is it worthwhile to rewrite it in C
or Vala? I'm not convinced that the answer is always (or even often)
yes. A rewrite is even worse than a fork in terms of waste, and given
that any nontrivial software is the product of thousands of
person-hours, there had better be several extremely good reasons.

-- 
http://homes.eff.org/~barlow/EconomyOfIdeas.html
http://www.dreamsongs.com/MobSoftware.html
http://www.gnu.org/philosophy/shouldbefree.html