On Wed, 22 Jun 2011 20:36:21 +0200 (CEST) "Nicola Pero" <nicola.p...@meta-innovation.com> wrote:
> > Huh, I see no reason for this rename. It'll just make patches across > > releases harder. > > Sure. But any change will make "patches across releases harder" ... does > it mean we can't make any changes - not even in phase 1 ? :-( > > The reason I'd like to change the name is that "attribs.c" is meaningless. > I never realized it contained code to deal with attributes until I opened > the file and read the code inside. I always thought it contained some > sort of mysterious internal GCC data structure or pass. Isn't that a good > enough reason to rename it ? :-) I agree with such renames and clean-ups, but I also sadly think there are very difficult in the GCC community (because old-timers who could approve that don't care, and don't like such patches). In an ideal world, I would like many patches like this. In particular, I would like some consistent naming conventions (that would contribute to define what modules are in GCC - so far, we do have "modularity efforts", but I still believe that we don't have yet modules: we cannot name them, and we cannot even count them, so in my view they don't exist yet; some nice old-timers have been upset because I told that GCC is not modular, but since GCC modules are not counted nor named yet, I still believe that GCC is not made of well defined modules - and that is what I mean by "modularity"; for many GCC gurus, it is only a relative qualification -unrelated to any set of modules-, and GCC is indeed slowly improving in that aspect.). An example of patches I dream about but would never dare submitting is a patch consistently renaming every GCC optimization pass (of struct opt_pass type, or its subtype). I feel that it would help a lot new people (and even me) if consistently every pass whose name field is "FOO" is named FOO_pass (or pass_FOO, I don't care about what convention we use provided we use it consistently & systematically). And for the same reasons your patch renaming "attribs.c" to "attributes.c" is rejected, I believe such a patch (renaming consistently passes) would also be rejected. It is very sad. Many GCC gurus don't see the point to make GCC code easier to read to newcomers (since such a change would temporarily make GCC code harder to read & to patch for them). This is sad, but won't change. As a counter example, I do find GTK (& related libraries) a lot more modular and more readable than GCC code - both coded in C; naming conventions, separation of modules as different libraries, usability as a library, documentation generated from code, younger age.... explain a lot. But GCC is too big and too important (and probably working well enough) to change a lot. So while I do welcome a lot patches like the changing of attribs.c to attributes.c advocated by Nicola Pero (and I admire his courage), I sadly believe they won't happen (unless proposed by a very select & closed circle of people). Perhaps the long term goal of progressively rewrite GCC in C++ might help (but I am a bit skeptical here too, I don't see lot of code on this point.). I don't like C++, but I believe that it could perhaps push such a rewrite (but I am pessimistic on the short run). There is an economical explanation for this: no corporation (not even the richest ones like Google, IBM, ...) is willing to spend money paying GCC developers to re-factor or rewrite parts of GCC. And such a massive effort won't happen freely (i.e. without investment). Besides, some organizations or people knowing very well GCC have no interest in such changes. And indeed, few people could promise that such a rewriting would improve GCC by a significant, predictable, & measurable amount. Sadly, GCC is almost nearly good enough for most corporations investing in it (so they can invest only in "marginal" improvements, even if "marginal" may mean several person-years to them!). Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
