On Sun, 18 Mar 2012 13:11:05 -0400
Robert Dewar <de...@adacore.com> wrote:

> On 3/18/2012 12:56 PM, Basile Starynkevitch wrote:
> 
> >     * you can name and count the modules of a software
> 
> Well in a hierarchical system this is not so clear, since modules may
> exist at different levels of abstraction. 

Agreed. Modules could contain submodules (but then I view this more as a 
language
feature, e.g. Ocaml's modules). I would like first that the GCC community 
sort-of agree
on a list of a dozen or two modules (call them super-modules or top-level 
modules if you
like). Obviously such modules would be quite large (since GCC is 5 or 10MLOC, 
having it
made of 30 modules mean that modules are several hundred thousand lines of 
source code
each, which means dozens of source files each). I don't think that we should 
organize GCC
as a large set of non-hierarchical modules: describing GCC as made of 200 
top-level
modules won't help newbies to understand it; the description should speak of a
few dozen top-level parts 


> >
> >     * given a source line, or function, you can decide at a glance to which 
> > one module it
> > belongs
> 
> This seems totally bogus, if you have something like
> 
>      n++;
> 

I expressed wrongly myself. If you know that 
    n++;
was in file foo/bar.c line 34 [which I meant by a source line, not an isolated 
set of
tokens newline terminated] you should know that it belongs to some module. 
Actually, I
believe that modules are a large set of source files (e.g. if GCC was made of 
two dozens
of modules, each module would probably be made of some dozens of files), so the
requirement is becoming: every source file belongs to exactly one module, and 
every
module is made of a set of source files.

> you can't tell what module that belongs to, and if your idea is that
> all variables should be long enough to know immediately what module
> something is in, I would regard that as plain horrible and highly
> undesirable.

Long names are relevant only for exported names, usable outside of the module.

> >
> >     * the interface between modules is well documented
> 
> Sure that's apple pie and motherhood, so it says nothing

No, it implies that something which is not documented should not be used 
outside of the
module (irrespective of any protected: or private: annotations in C++) and this 
is a
strong coding rule (which is probably not enforced in GCC today). The 
documentation can
(and should) be generated (à la doxygen), which translates that requirement 
that only
API defined by structured comments understood by doxygen can be used outside of 
a module

> >
> > I'm sorry to say that, but current GCC (ie 4.7 or today's trunk) is *not* 
> > modular.
> 
> Modularity is not a binary quality, so this is not a helpful statement

IMHO modularity is an all or nothing quality. Our terminology differs!

> 
> > Don't
> > feel injured by that fact. Indeed, GCC is a little less messy than it was a 
> > few years
> > ago, but being less messy is not being modular IMHO. And something cannot be
> > "half-modular".
> 
> Absolutely it can, parts of the system can be arranged nicely into 
> modules, and parts of the system may not be.
> 
> > So I would be delighted if GCC was made of modules. But I have no idea of 
> > how that can be
> > done.
> 
> Then your comments are not at all helpful, since they just
> reflect vague goals which everyone agrees on.

No, I was expressing the wish that qualified people having a global 
understanding of GCC
(which I have not) would propose a well defined and small set of modules

> 
> > I do believe that identifiers in GCC should be organized in such a way that 
> > the module
> > they belong to is visible at once. I think that a prefix (à la GTK) or a 
> > C++ namespace
> > should be great. In particular, this means that most GCC identifiers should 
> > change
> > (which means that any such evolution is not syntactically gradual; it has 
> > to be made by
> > huge, but "easy", patches).
> 
> I am of the opinion that this would severely damage readability, it's 
> the same sort of thing that leads people in Ada to avoid use clauses
> completely.

I have absolutely no idea if the Ada parts of GCC can be made of several 
modules or not

> 
> Since in any decent IDE it's just a single click to find out where a 
> variable is declared, it's just noise to include this information in
> every variable name. Of course global variables with wide visibility
> should have appropriate names, but the idea that all identifiers
> should be prefixed is horrible IMO

Namespaces in C++ gives you exactly that. If we go the C++ route, why should we 
not use
namespaces for modules? If we stay in C, then we can have prefixes, and GTK 
experience
shows that it is helpful and not horrible (any decent editor has good 
completion),
contrarily to your claim (of course I am speaking only of exported identifiers, 
usable
from other modules). When you code in Gtk in C you know at a glance to which 
module a
given public identifier belongs (and in which source files you can find its
implementation). This helps a lot.

Regards.


-- 
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} ***

Reply via email to