On 13-11-10 03:02 PM, Lex Trotman wrote:
[...]

Yes, I understand how the "throws" are implemented in vala, but as I said,
the existing C code isn't designed to handle that.


Much of the existing code uses GError-style errors, and any existing C
code that was made to to call Vala generated code would do the same, no
biggie. It's not like we'd throw an exception from a re-written function
without updating the caller code, that wouldn't even work, the compiler
would have a fit about missing (GError) parameter (unlike with C++
exceptions).

Maybe I misunderstand your point still?


No, you said it exactly right, the concern is we can't use Vala
"exceptions" without changing the existing C code, which somewhat negates
the benefits of Vala.


True, but it's not exactly difficult to update/add an argument on a C function, I think the compiler will kindly (or rudely :) even point out all the places that were missed.

[...]

Or you honestly don't think Vala is a good fit at all for new/re-written
parts of Geany code?


Not yet convinced, and TBH not really convinced about a progressive change
to C++ either (my original mention that sparked the thread was meant to be
a sarcastic throwaway comment :).  I understand your desire to keep the
discussion high level, but the devil is in the annoying little details for
languages, and their implementations, so you can't make a decision without
examining those details.


I agree about C++, however much of a better language it is, it's not a great fit in Geany as it stands (although could probably be workable using GTKmm). IMO, Vala is the simplest way to get the most bang with least amount of friction with existing code/framework and all of the output C code from Vala is quite readable and for the most part maps 1:1 to what we (at least me) would've wrote anyway.





  To be clear, tinkering with what language is used to tack more bandages on
to the current Geany design is a waste of time.  Choosing a better
language
to implement a better design might be worthwhile.


That's the idea; choose a better language, agree it can be used, and then
start working on the re-factoring/re-design stuff using it. If we get
bogged down at this point with deep design discussions and stuff, instead
of just agreeing on a language that volunteers (ex. me) are
happy/willing[1] to use to roll-out said re-factorings/re-designs, we'll
not move forward at all[2].


As I said, choosing the language first is putting the cart before the
horse.  As I said in reply to Colomban, I'll start a different thread about
the way we want to move, lets see where that goes.


If you're going to renovate a house, it helps to know whether you're going to use lumber or concrete before you start designing the structure :)

I don't think it's putting the cart before the horse, but I agree the two things aren't directly related, either one could happen in either order, just that if we chose to use Vala before any major changes/redesigning, we'd save a lots of pain in the process (to use above metaphor, we could save driving nails into concrete, or pouring lumber into concrete molds :)

Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Reply via email to