Alexandre Prokoudine wrote:
> It has *something* to do with too much gobject boilerplate code.

It's a good thing I asked that we clarify the problem as I was thinking it
was something else entirely. Pointers to a couple of files that show the 
issue of a lot of boilerplate code would be good so we can all see the 
extent of the problem.

If the problem really is with gObject and the need for a lot of boilerplate 
code there are several options.

1. Don't use gObject.
Just including this for completeness since it is very unlikely to happen.

2. "Fix" gObject.
Update/improve gObject so it doesn't require so much (or any?) boilerplate 
code. I've been looking at two other OOP languages and haven't seen the need 
for boilerplate code. If its needed with gObject its either a design issue 
of gObject or due to the complexity of GIMP objects.

3. Create template file(s) with all the typical boilerplate code.
If people are copying from existing files it might be easier to just create 
some template files that can be used as the starting point.

4. Write a program to generate the boilerplate code.
If template files could not be made to handle the typical use cases, a 
program could be made where a person could answer questions or set options 
and have it generate a file with all the required boilerplate code.

5. Use a "chanting" system similar to what is used in BABL and GEGL.
The chanting system in BABL/GEGL seems to work well in that it makes it easy 
(or easier) to work with things like the GEGL operation files without the 
need for a deep understanding of gObject.

6. Use some other programming language to avoid having to write boilerplate 
This option is really just another way to avoid having to write boilerplate 
code by hand.

If vala (or language x) is used to avoid the need for all the boilerplate 
code there are still a number of issues:

1. Time to learn gObject vs. time to learn vala
2. Time to change code to be vala based instead of raw gObject.
    - Need to know both system while migration is taking place
3. How many GIMP developers can write code in vala?
4. How many GIMP developers who know vala are free to work on the migration?
5. How much of GIMP would need to be updated/modified/rewritten in vala?

I think throwing another language in to the mix is the wrong way to address 
the boilerplate issue.
Gimp-developer mailing list

Reply via email to