[...] > 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. [...] > We could compile own if we need to embeded release, otherwise using >>> something like https://wiki.gnome.org/Vala/Win32CrossBuildSample or >>> billions of other possibilities for creating cross-platform code as well >>> as >>> we do now. >>> >> >> >> Sure we *can* do anything, but "somebody" has to do it and maintain it. >> >> > I'm volunteering. We keep saying "somebody" has to do it, and I'm > proposing a way that seems the most sane/best and least time-wasting to do > it, and being the "somebody" in this case (although I'm hardly a build > system expert). > > Look forward to its appearance on github.com/codebrainz/geany :) > > [...] >> >>> >>> >> >> Nope, I propose *new* Geany release will only work on *new* dependencies, >>> which are release in *new* distros, which are using *non-deprecated* >>> APIs. >>> >>> >> So you want the extra work of backporting bugfixes, or just forget about >> older platforms? >> >> > I guess (according to Columban's message) this is a non-issue, we can > target same versions of stuff as before, and even RHEL supports recent > Valac, so it should be same old (in theory at least). Makes sense that it should work on Linux, and if you make a Windows bundle as above then fine. [...] > I would have thought that "no" above was obvious. >> >> > Is that "no" because you want to focus on re-design and not getting an in > principle agreement on a good language to use? Correct. > 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. > > > 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. > > P.S. Sorry if I was snarky/sarcastic in the last message, it's only > because I know roughly your sentiments on the subject from our previous > discussions, and could insert any topic for Vala and you'd find some points > to disagree about (see most/all RFCs in ML archives) :) I just get > frustrated because you're generally against every idea anyone (especially > me) has, and it's hard to tell if you're being genuine or just disagreeing > for the sake of disagreeing, or you think I'm too stupid to understand what > I'm talking about or something. > There is definitely nothing personal about any disagreement over things. I guess you see most disagreements simply because you post the most proposals, and thats a positive not a negative. As I said above the devil is usually in the details, and after having been bitten many times I tend to focus on the things that might cause problems, because the things that are right will look after themselves. I guess that can look negative, but its simply trying to prevent issues I see before they happen. Cheers Lex > > Cheers, > Matthew Brush > > > [1]: I'd also be willing to do in plain GObject/C but it'd be a lot more > boring/long/bug-prone and would result in the exact same code as Valac > would generate (or likely worse), and then you'd be pointing out about how > it's too much churn, boilerplate, or how G*/C sucks, etc. > > [2]: Yes, the design part is fairly independent of the language part, of > course we could do it ASM if we wanted, but certain tools make things a lot > easier to express/organize, especially when you can type 20 lines of clean > readable Vala code instead of 200 lines of organized but boring GObject > code, or 150 lines of unstructured, bug/leak-prone, hard-to-follow plain C > code[3]. > > [3]: And yes, it is possible to write structured, non-buggy/leaky, easier > to follow code in plain C, but it's a heck of a lot harder, and as shown in > existing Geany code, it's easier to be less rigorous when the proper > "framework" of the code isn't in place. > > _______________________________________________ > Devel mailing list > Devel@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel >
_______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
