On 13-11-12 07:50 AM, Frank Lanitz wrote:
I cannot add much to the vala yes/no question, as the only part of ala I've seen by know are Matthews's plugin in g-p. Two or maybe three things are important to me, in case of:
- Geany needs to keep its small memory footprint
Yes, I don't think there'd be an appreciable[1] extra amount of memory, it uses all existing libraries we have loaded in memory anyway, and Vala has special annotations and stuff to tailor the generated C code for when you need to optimize for special cases.
- Created code needs to run on all plattforms Geany currently is running
on -- At least I know of *BSD, Solaris,, MacOS X, Windows, Linux and we need to stay compatible with curent stable versions of SLES, RHEL etc. which means at least RHEL 5.x and SLES 10. Also at least for the next year we need to keep on running on Debian Squeeze also.
Yep, it's just GObject code, so anywhere GTK+/GObject runs, the code compiled out of Vala should run just the same.
- There needs to be a final, let's call it C-only-release (well, having
1.24 in some would be a good idea anyway)
+1.
- g-p should keep on running: We got a lot of badly maintained, but good
used plugins. If a major rewrite is needed for them, I doubt it will be done for a huge number of.
Not strictly related to Vala but more to the other thread, I doubt this is feasible/possible with upsetting the plugin API to some degree, given the scope of the changes being discussed there[2]. On the bright side, with the possibility of exposing the plugin API to higher-level, more user-friendly languages (via generatable bindings and such) we could see a boon of nice new plugins, written in much more maintainable languages, by a more diverse class of developers, and much less ability to bring Geany down to a crashing halt with one little pointer mishap :)
Cheers, Matthew Brush
[1]: Of course this is subjective but even just something like using GTK+3 build probably dwarves anything introduced by some additional GObjects generated out of Vala.
[2]: Since so much of Geany's guts/implementation is exposed directly, it'd most likely be impossible to make any non-trivial changes/re-factorings without disturbing the plugin API. And even if we aimed to keep the plugin API mostly stable during the changes, we'd probably end up with maintenance nightmare of all kinds of old backwards compatibility wrappers and such.