<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 11 November 2013 02:40, Colomban Wendling <span dir="ltr"><<a href="mailto:lists.ban@herbesfolles.org" target="_blank">lists.ban@herbesfolles.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 10/11/2013 05:44, Matthew Brush a écrit :<br>
<div class="im">> Hi all,<br>
><br>
> In the spirit of the previous discussions about using C99 and C++ in<br>
> Geany code with similar subject lines, I'd like to take a<br>
> poll/discussion for allowing the use of Vala for new/re-written Geany<br>
</div>> code. [...]<br>
<br>
Well… it's a little complicated. I agree that features from a<br>
higher-level language could help, it being C++, Vala or something. It's<br>
definitely shorter to write some things in those languages than in C,<br>
and memory management is definitely easier. I see one advantage in Vala<br>
over C++: that it actually is C ([1]), just like our current code. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I agree that Vala would help if we want to port the code to something<br>
more OOP-style -- since obviously the language supports it by itself. I<br>
agree it's probably a good idea. But the port won't happen magically.<br></blockquote><div><br></div><div>Yes, what I tried to express was that the problem is the design and organisation of Geany, and just changing the language won't change that without an actual effort to do so. But thats not the subject here so I'll start another thread for it.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The problem I see is that using C from Vala requires a more or less<br>
manual interfacing, even if quite easy to write. This adds actual<br>
complexity. We could try by porting leaf modules to Vala and see (maybe<br>
utils?) -- since calling Vala API from C is native --, but it's probably<br>
not the modules that would benefit the most from the language.<br></blockquote><div><br></div><div>Interesting that you say that, I proposed exactly the opposite based on being able to define the APIs of existing leaf C code in vala and a vala skeleton/infrastructure/framework (choose your preferred term :) is guaranteed to be able to call them. Whereas I thought that adding Vala at the leaves meant you had to make the Vala API match the existing C one or you had to change the existing C code to match the Vala API. In the first case you don't get the full Vala benefit as you say [2]. In the second case if the C core calling Vala has to change so it might as well be done in Vala in the first place, but that of course increases the size of each change.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To sum up, my point is that having more than one language might add too<br>
much of a glue layer for it not to weight down the idea.<br></blockquote><div><br></div><div>Yes, it makes the way I proposed less progressive I suppose, the vapis need defining and maintaining.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Sorry Matthew, but it's kind of an "I like Vala but I don't know" :)<br>
<div class="im"><br>
> * Actively developed so sometimes we probably have to require specific<br>
> valac versions to support certain features (ie. nothing like c89, c99,<br>
> c++98, etc but not unlike supporting newer G* versions).<br>
<br>
</div>Not to mention bugfixes in bindings, that are much less frequent today<br>
but weren't rare a dozen months ago or something.<br>
<div class="im"><br>
> * As with above, may require to use fairly modern/specific dependency<br>
> versions of the G* C libraries (ex. might not work on RHEL or some other<br>
> LTS distros).<br>
<br>
</div>I think Vala supports targeting a particular GLib version for what it<br>
itself generates (vs. what API you explicitly use in your own code), so<br>
it may not be an issue. And I think e.g. GTK is just a lib to Vala's<br>
eyes, so you just have to use the part of it that match your preferred<br>
version, just like we already do.<br></blockquote><div><br></div><div>That should always work for Linux, but there is always the Windows issue.</div><div><br></div><div>Cheers</div><div>Lex</div><div><br></div><div> [2] and if you are using Vala to mimic existing C interfaces then you are constrained in some of its features as I understand it. For example Vala "exceptions" require an Error return in the function signature, which our existing C functions don't have.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Regards,<br>
Colomban<br>
<br>
<br>
[1] so allows to keep full C compatibility without only using an<br>
uninteresting subset of the language, unlike the C++ discussion<br>
suggested, which was basically "use C++ but nothing in headers that's<br>
not C compatible, so excluding classes, and much of the interesting<br>
stuff in C++".<br>
If you wanna continue on this, use another thread :)<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.geany.org">Devel@lists.geany.org</a><br>
<a href="https://lists.geany.org/cgi-bin/mailman/listinfo/devel" target="_blank">https://lists.geany.org/cgi-bin/mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>