In article <D8B00G.5Ht@news.informatik.uni-stuttgart.de>,
Dirk Farin <farindk@trick.informatik.uni-stuttgart.de> wrote:
>If you write class definitions like this:
>
>class A { };
>class B { class A a; };
>
>everything is fine. But if you only change the order of these two
>definitions:
>
>class B { class A a; };
>class A { };
>
>it can't be compiled. This rule seems to exist to make compiler-design
>easier. But from a software-engineering point of view this not only
>makes no sense but only destroys the ability to order the code the
>way you think it is logical.
>How would you think about loosing this dependency-rule? It surely will
>make compiler-design a bit harder but software-design easier.
>However this would not interfer with the current language definition.

 you use a tool better than a text editor.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

|farindk@trick.informatik.uni-stuttgart.de (Dirk Farin) writes:
|
|>If you write class definitions like this:
|
|>class A { };
|>class B { class A a; };
|
|>everything is fine. But if you only change the order of these two
|>definitions:
|
|>class B { class A a; };
|>class A { };
|
|>it can't be compiled. This rule seems to exist to make compiler-design
|>easier. But from a software-engineering point of view this not only
|>makes no sense but only destroys the ability to order the code the
|>way you think it is logical.
|
|I have to disagree with your premises. Why is it MORE sensible and
|logical to use something which hasn't been defined? I claim that in
|general it is more sensible and logical to use only those things
|which have been defined.

I agree with Dirk, from a software-engineering point of view, loose
ordering is usefull. The mere you think of your project, have concern
of readability or maintenance issue, etc, the finer. Were did you saw
anybody wrote it is MORE sensible to use one order or the other ?
I understand Dirk's claim as *don't prejudice about which order is
logical in my code*. For example, I prefer showing interface of external
object before showing it's inner parts (implementation details). With
the stong order rule you makes me go the other way.

I agree with you when you write that it is more sensible to use
only things that have been defined, but that is obviously the case
(if you compile your source files *after* writing them as I do).
For all I know, nothing forbid a compiler to read source files backward.
Is it a a standard issue ?

|>How would you think about loosing this dependency-rule? It surely will
|>make compiler-design a bit harder but software-design easier.
|
|It would mean that in general the entire compilation unit would have
|to be processed twice. It wouldn't just mean compiler design would
|be harder, but compile times would be longer and require more
|resources (memory, disk space) than they do now. That seems a high
|price to pay for essentially no benefit. Just order your definitions
|so that they occur before use. It isn't really very hard.

I felt the above statements is really more appropriate for C than C++.
The C++ compilers have already many choices that must be delayed
until some definition is known at compile time. Loose ordering seems
to be another one. Don't you overestimate a bit the costs to end the point ?
Even if the code should really processed twice and that it's not already
the case, Algorithmic complexity is still the same and Processors, Memory,
disk space, etc. are cheaper every day (hardware changes faster,and often more
fondamentally than software).

I am myself against looser ordering (not apparent from the above) for
a problem of good programming practice : two classes can't be mutually
dependent so the strong ordering rule is a way to ensure such horrors
won't be written by uncaring newbies. But that is the only reason I have.

I feel *it makes compiler simplers* is a very poor point,
I saw it used about features that would probably simplify compilers,
my point is when something is hard to compile, similar usefull cases
are probably hard to compile too, and the price should be paid,
the sooner the better.
(not so when the point is *generated code would be more complex, slower*)

If you write class definitions like this:

class A { };
class B { class A a; };

everything is fine. But if you only change the order of these two
definitions:

class B { class A a; };
class A { };

it can't be compiled. This rule seems to exist to make compiler-design
easier. But from a software-engineering point of view this not only
makes no sense but only destroys the ability to order the code the
way you think it is logical.
How would you think about loosing this dependency-rule? It surely will
make compiler-design a bit harder but software-design easier.
However this would not interfer with the current language definition.

-------------------------------------------------------------------------------
                        ^^
  Dirk Farin           oo )        farindk@trick.informatik.uni-stuttgart.de
  Kapellenweg 15      =x= \
  72070 Tuebingen       |  \       tel. +49 7071 71461 (voice / modem)
  Germany               |  _\
                       ((_(__)
-------------------------------------------------------------------------------

farindk@trick.informatik.uni-stuttgart.de (Dirk Farin) writes:

>If you write class definitions like this:

>class A { };
>class B { class A a; };

>everything is fine. But if you only change the order of these two
>definitions:

>class B { class A a; };
>class A { };

>it can't be compiled. This rule seems to exist to make compiler-design
>easier. But from a software-engineering point of view this not only
>makes no sense but only destroys the ability to order the code the
>way you think it is logical.

I have to disagree with your premises. Why is it MORE sensible and
logical to use something which hasn't been defined? I claim that in
general it is more sensible and logical to use only those things
which have been defined.


>How would you think about loosing this dependency-rule? It surely will
>make compiler-design a bit harder but software-design easier.

It would mean that in general the entire compilation unit would have
to be processed twice. It wouldn't just mean compiler design would
be harder, but compile times would be longer and require more
resources (memory, disk space) than they do now. That seems a high
price to pay for essentially no benefit. Just order your definitions
so that they occur before use. It isn't really very hard.
--
Steve Clamage, stephen.clamage@eng.sun.com