D - My comments on D after a first look - dtest.html
- PIEBALDconsult aol.com (177/177) Aug 22 2003 Greetings:
- Mike Wynn (61/61) Aug 22 2003 charset="iso-8859-1"
- Scott McCaskill (15/20) Aug 24 2003 style.
- Samuel Barber (11/14) Aug 25 2003 executable
- Sean L. Palmer (16/30) Aug 26 2003 "Go to declaration" is your friend.
Greetings:
-----
Before I start listing what I feel are some shortcomings of the language let me
have involved just plain C... VAX C and DECC at that. And that was with embeded
SQL as well. So please bear that in mind.
Also, I just joined this list and have not read the previous messages, so please
excuse me if I repeat any subjects that have been brought up and argued.
-----
through to the next case in the absence of a break statement.
-----
I don't see any reason to have the ability to insert D code in HTML as a feature
of the language, that seems to make no sense. At most I see it as a feature of
the compiler, not the language itself. Further, why even have it as a feature of
the compiler? Why not simply have it as a standalone tool? Then the tool can be
used with other languages; e.g. C.
My main reason for saying that it makes no sense is that generally documentation
doesn't contain the actual code of the application being documented. The only
people who need to see the code would be seeing the internal comments and such
anyway.
And library users only need to have the interfaces documented. In the case of
open source, the user has access to the actual code.
When I was creating HTML documentation for my C library the only bits of code I
included were done like:
<acronym title="typedef int MYTYPE">MYTYPE</acronym> myfunc ( ... ) { ... } ;
But a bigger concern about this feature of the compiler (other than that it's
non-sensical) is that it causes trouble (see below and attached) which can only
be solved by modifying the code so that it will work, and that's bad... and
ugly.
In fact I suggest two standalone tools; one to HTMLify the code, and one to
extract the code from the HTML. The user would write the code as usual and then
HTMLify it to form the documentation, as silly as that documentation would be.
-----
Why continue the awful C format of the date as a string, why not elevate
yourself above the muck and use ISO8601 format? And where does the date system
get the timezone and DST information? Again, be better than C in this, include
the time zone and DST settings in the basic time value object (d_time).
-----
In my C code I use __FILE__ and __LINE__ and also __FUNC__ when I'm writing
messages to a run log (I never heard of assert() until I read the D
specification). Assert() won't work for me because I need to include the date
and time (in ISO8601 format). So I suggest these be included in the language.
But of course I have also already proven to myself that I can pass the D code
through a C preprocessor to take care of that (other than __FUNC__ which
actually is not handled by the preprocessor), as well as the other C
preprocessor directives like #define and #include. Ha ha! Take that!
-----
I prefer C's requirement that all declarations in a statement block appear
before any executable code. Allowing the mixing of declarations and executable
may make it difficult to find a declaration, which is poor programming style.
I do however like the ability to declare the iterator of a for statement within
-----
Concerning modules...
In C I can put each function in its own file, compile them and put them in a
library, then link the library into the executable (after #including the header
file(s) of course).
This allows a team to work on the code more easily; Abe doesn't need to wait for
Betty to finish her work on the code when each needs to modify different
functions, as would be the case when both functions are in one file. Also, when
using a version control system (SourceSafe, CMS, whatever) you would see that
the file was changed, but you'd need to see the comments (provided they were
updated) to know which function(s) was changed, having one function per file
solves that. Plus, doing an incremental build is quicker if only the changed
function is recompiled rather than everything in the file.
With D, each of those functions would be in its own module? Would they have
trouble referring to each other? Would there be trouble building them?
C can do it because code that calls a function in a different file only needs to
read the prototype in the header file, but D doesn't have prototypes and header
files so it needs to read the whole source file (yuck!).
With C++, separate files for the methods can still be done because of the
needs to do that, but why does D? Is it simply because you don't like
prototypes?
Although I guess I can do something like:
class X
{
int y ;
#include "x_func.d" // Contains code for X::func()
}
But then I still need to recompile everything even though there may be only a
small change, probably a shortcoming of OOP.
Plus, the line numbers would be of no help in debugging.
-----
In the specification (I read the PDF version) it lists as a shortcoming of
#define macroes that they can't declare variables... of course they can:
#define REPEAT(x,y) \\ Repeat statement x y times \
{ \
int i ; \
for ( i = 0 ; i < y ; i++ ) \
{ \
x \
} \
}
-----
Another benefit of #defined macroes is it allows things like:
#define abs(x) ((x)<0?(x)*-1:(x))
which doesn't care whether it's passed an int or a float and so you don't need
to write a separate function for each type. And you don't need to change the
call if you change the type.
As far as abs is concerned, perhaps it should be a method? And a method to
change the sign?
-----
<html>
<head><title>Naughty D code in an HTML file</title></head>
<body>
<center><h1>Examples of D code in HTML that don't work correctly</h1></center>
And I realize that all or most of the problems are due to poor style, that there
<em>should</em> be spaces around the operators and such.
<hr>
<code>
import c.stdio;<br>
<br>
int<br>
main<br>
(<br>
char[][] args<br>
)<br>
{
<blockquote>
int nbsp=1;<br>
int quot=3;<br>
<br>
int test1=quot <br>
; // Added so the thing will compile<br>
int test2=quot&nbsp;<br>
<br>
/+ Not fixable like the previous one<br>
int test3=nbsp"<br>
+/<br>
int test4=nbsp&quot;<br>
<br>
printf("test1==%d\ntest2==%d\ntest4==%d\n",test1,test2,test4);<br>
<br>
char[] test5="<H1>Whoops!</H1>";<br>
char[] test6="<H1>Ah, that's better.</H1>";<br>
<br>
printf("test5==%.*s\ntest6==%.*s\n",test5,test6);<br>
<br>
return 1;
</blockquote>
}<br>
</code>
</body>
</html>
----------
John
PIEBALDconsult aol.com
begin 0644 dtest.html
M17AA;7!L97, ;V8 1"!C;V1E(&EN($A434P =&AA="!D;VXG="!W;W)K(&-O
M;&P ;W( ;6]S="!O9B!T:&4 <')O8FQE;7, 87)E(&1U92!T;R!P;V]R('-T
M>6QE+"!T:&%T('1H97)E(#QE;3YS:&]U;&0\+V5M/B!B92!S<&%C97, 87)O
M:6UP;W)T(&,N<W1D:6\[/&)R/ T*/&)R/ T*:6YT/&)R/ T*;6%I;CQB<CX-
M8VMQ=6]T93X-"B` ("!I;G0 ;F)S<#TQ.SQB<CX-"B` ("!I;G0 <75O=#TS
M("` :6YT('1E<W0R/7%U;W0F86UP.VYB<W`[/&)R/ T*/&)R/ T*("` ("\K
M($YO="!F:7AA8FQE(&QI:V4 =&AE('!R979I;W5S(&]N93QB<CX-"B` ("!I
M06 L('1H870G<R!B971T97(N)FQT.R](,29G=#LB.SQB<CX-"CQB<CX-"B`
M("!P<FEN=&8H(G1E<W0U/3TE+BIS7&YT97-T-CT])2XJ<UQN(BQT97-T-2QT
M97-T-BD[/&)R/ T*/&)R/ T*("` (')E='5R;B`Q.PT*/"]B;&]C:W%U;W1E
G/ T*?3QB<CX-"CPO8V]D93X-" T*/"]B;V1Y/ T*/"]H=&UL/ T*
`
end
Aug 22 2003
"Mike Wynn" <mike.wynn l8night.co.uk>
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<PIEBALDconsult aol.com> wrote in message =
news:bi669l$2b4e$1 digitaldaemon.com...
Greetings:
-----
In fact I suggest two standalone tools; one to HTMLify the code, and =
one to
extract the code from the HTML. The user would write the code as usual =
and then
HTMLify it to form the documentation, as silly as that documentation =
would be.
-----
I would agree that D code should be in D syntax, if you want html write =
a tool to either convert or strip.
I prefer C's requirement that all declarations in a statement block =
appear
before any executable code. Allowing the mixing of declarations and =
executable
may make it difficult to find a declaration, which is poor programming =
style.
I do however like the ability to declare the iterator of a for =
statement within
-----
the beging of a scope
in C it is valid to write
void func( int i ) {
printf("i is %d\n", i);=20
{
int j =3D i+5;
printf("j is %d\n", j);=20
}
}
not too far removed from
void func( int i ) {
printf("i is %d\n", i);=20
int j =3D i+5;
printf("j is %d\n", j);=20
}
With C++, separate files for the methods can still be done because of =
the
class::func() { ... } syntax. This seems to be impossible with D (and =
the methods must be fully declared inside the class (yuck!). I can see =
needs to do that, but why does D? Is it simply because you don't like
prototypes?
-----
all I can say is how bigs you project and how much effort do you have to =
put in to keep the headers inline with the implementations (and why =
write them twice).
get an editor that does code folding,=20
the benifits of having implementation and interface defined together =
outweighs the slightly larger files (imho) ( yes I have been know to =
write 3 sub classes in 3 separate modules just to keep the code =
separated but still prefer it as it is).
I do prefer the Java one public class per file , and would like D to =
allow a class per file or a module per file.
Aug 22 2003
I prefer C's requirement that all declarations in a statement block appear before any executable code. Allowing the mixing of declarations andexecutablemay make it difficult to find a declaration, which is poor programmingstyle. OTOH, if a variable isn't used until almost the end of the scope, you have go back to the beginning of the scope to figure out what it's type is, and (in D) this style will also incur some redundant initialization in many cases since (IIRC) all variables are default-initialized. In any case, if finding the declaration is a problem, it's usually because the scope has gotten too large and should be broken up into multiple functions. Incidentally, for these reasons and others, many C++ programmers consider this practice to be poor programming style.I do however like the ability to declare the iterator of a for statementwithinThen it sounds as though you may already appreciate at least some of the value of not being forced to declare all variables at the start of the scope. Scott McCaskill
Aug 24 2003
<PIEBALDconsult aol.com> wrote in message news:bi669l$2b4e$1 digitaldaemon.com...I prefer C's requirement that all declarations in a statement block appear before any executable code. Allowing the mixing of declarations andexecutablemay make it difficult to find a declaration, which is poor programmingstyle. It's the worst style, except for all the others. In C, you can open new scopes, but programmers rarely do because they find the nesting ugly. The other option, declaring variables long before use, makes it harder to determine the true lifetime of a variable, how it's being used, whether it has been initialized properly, etc. The declaration is just one piece of information, not everything you need to know. Sam
Aug 25 2003
"Go to declaration" is your friend. Browse info generation gives you the power to instantly unravel arbitrarily complicated code a step at a time. Do you need anything else? You certainly can't hope to force all programmers to use single-page functions! compilation. It underlines errors as you type, etc. One of these days you probably won't need a "rebuild" button at all. That said, I hate seeing functions with variable declarations all at the top because I have to jump back and forth across pages to see them. Oftentimes I regret even having to specify a type. I've witnessed many a bug that was a bug in a declaration that was hidden because the bug was far away from the declaration; your brain never sees them together at the same time. Sean "Samuel Barber" <opendtv yahoo.com> wrote in message news:bielig$5gt$1 digitaldaemon.com...<PIEBALDconsult aol.com> wrote in message news:bi669l$2b4e$1 digitaldaemon.com...appearI prefer C's requirement that all declarations in a statement blockbefore any executable code. Allowing the mixing of declarations andexecutablemay make it difficult to find a declaration, which is poor programmingstyle. It's the worst style, except for all the others. In C, you can open new scopes, but programmers rarely do because they find the nesting ugly. The other option, declaring variables long before use, makes it harder to determine the true lifetime of a variable, how it's being used, whether it has been initialized properly, etc. The declaration is just one piece of information, not everything you need to know. Sam
Aug 26 2003