Martin Nordholts (enselic@xxxxxxxxx) wrote: > I'm trying hard to find time hacking on GIMP, and not having to waste > time on GObject C boiler plate means a lot to me. At first I was > thinking "what the hell, I'll just come up with the the damn > boilerplate code manually then". But right after I began doing that I > started to feel like I was wasting my time, and I can't stand that > feeling. Hm. This paragraphs leaves me a bit perplexed, because it gives the impression that the most important thing about including vala is to make you more comfortable with our codebase. You blame mitch for a blunt dismissal, but this reads a lot like bluntly forcing down something through mitchs throat. Not sure if that is any better. I must say that - while I have my share of frustrations with the gobject boilerplate code - I don't think that adding vala helps the quality of the Gimp codebase. And this is IMHO what should be in our focus. >From reading a lot of code in a lot of different free software projects I have to say, that Gimp still is one of the shining examples regarding consistency and quality of the source code. This has a lot to do with mainly Sven and Mitch investing countless hours into refactoring and restructuring the code, enforcing a common code structure and generally fighting against sloppiness. I don't see how mixing this code with code written in a new language will help the quality of the source. Vala code will inherently develop a set of patterns that differs from the C code (and don't underestimate the value of grepping through the code base). Also new contributors will not only have to learn about GObject and GTK+, they have to learn vala as well. And adding vala *is* adding a new entry barrier, vala is by no means a lingua franca. Bye, Simon -- simon@xxxxxxxx http://simon.budig.de/ _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer