Ok, another question...as I read the specs, unittest() sounded like it only was available as a member function of classes.  But adi.d has a bunch of them out at module level.  I presume that this means that all of them are run automatically as the unit test of the module.  If this is correct, the QA dept should have noted that in the spec ;-)

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB50812.32369985@deming-os.org...

> Ok, another question...as I read the specs, unittest() sounded like it only was available as a member function of classes.  But adi.d has a bunch of them out at module level.  I presume that this means that all of them are run automatically as the unit test of the module.  If this is correct, the QA dept should have noted that in the spec ;-)

In fact, unittest is module-level function. See string.d, regexp.d...

Pavel Minayev wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB50812.32369985@deming-os.org...
>
> > Ok, another question...as I read the specs, unittest() sounded like it only was available as a member function of classes.  But adi.d has a bunch of them out at module level.  I presume that this means that all of them are run automatically as the unit test of the module.  If this is correct, the QA dept should have noted that in the spec ;-)
>
> In fact, unittest is module-level function. See string.d, regexp.d...

Yeah, it makes sense.  But it should be in the docs.  Also, the docs should note that one module can have multiple unittests.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB50E8C.EA1F02D5@deming-os.org...
> Pavel Minayev wrote:
> > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB50812.32369985@deming-os.org...
> > > Ok, another question...as I read the specs, unittest() sounded like it only was available as a member function of classes.  But adi.d has a bunch of them out at module level.  I presume that this means that all of them are run automatically as the unit test of the module.  If this is correct, the QA dept should have noted that in the spec ;-)
> > In fact, unittest is module-level function. See string.d, regexp.d...
> Yeah, it makes sense.  But it should be in the docs.  Also, the docs
should
> note that one module can have multiple unittests.

Bruce Eckel originally pointed out that D needed language support for unit testing. He showed me some of the kludgy ways it was done in other languages that weren't accommodating of the concept. Once I implemented it and tried it out, my thinking on how it should be used evolved and its role expanded. Unit testing has in my mind risen to become a main feature of D. For library functions it works out great, serving both to guarantee that the functions actually work and to illustrate how to use the functions.

Consider the many C++ library and application code bases out there for download on the web. How much of it comes with *any* verification tests at all, let alone unit testing? Less than 1%? The usual practice is if it compiles, we assume it works. And we wonder if the warnings the compiler spit out in the process are real bugs or just an irrelevancy.

Along with design by contract, unit testing makes D far and away the best language for writing reliable, robust systems applications. Nearly every one of those library routines had at least one bug exposed by the unit testing. Unit testing also gives us a quick-and-dirty estimate of the quality of some unknown piece of D code dropped in our laps - if it has no unit tests and no contracts, it's unacceptable.

(I'm going to regret making that last statement!)

Walter wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB50E8C.EA1F02D5@deming-os.org...
> > Pavel Minayev wrote:
> > > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB50812.32369985@deming-os.org...
> > > > Ok, another question...as I read the specs, unittest() sounded like it only was available as a member function of classes.  But adi.d has a bunch of them out at module level.  I presume that this means that all of them are run automatically as the unit test of the module.  If this is correct, the QA dept should have noted that in the spec ;-)
> > > In fact, unittest is module-level function. See string.d, regexp.d...
> > Yeah, it makes sense.  But it should be in the docs.  Also, the docs
> should
> > note that one module can have multiple unittests.
>
> Bruce Eckel originally pointed out that D needed language support for unit testing. He showed me some of the kludgy ways it was done in other languages that weren't accommodating of the concept. Once I implemented it and tried it out, my thinking on how it should be used evolved and its role expanded. Unit testing has in my mind risen to become a main feature of D. For library functions it works out great, serving both to guarantee that the functions actually work and to illustrate how to use the functions.
>
> Consider the many C++ library and application code bases out there for download on the web. How much of it comes with *any* verification tests at all, let alone unit testing? Less than 1%? The usual practice is if it compiles, we assume it works. And we wonder if the warnings the compiler spit out in the process are real bugs or just an irrelevancy.
>
> Along with design by contract, unit testing makes D far and away the best language for writing reliable, robust systems applications. Nearly every one of those library routines had at least one bug exposed by the unit testing. Unit testing also gives us a quick-and-dirty estimate of the quality of some unknown piece of D code dropped in our laps - if it has no unit tests and no contracts, it's unacceptable.
>
> (I'm going to regret making that last statement!)

I like it :)

And I'm sorry, I now see that unittest *is* documented under modules...I just jumped to the conclusion that they were only for classes. :/

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

IMHO, you really need to stop focusing on the "system" aspects of D.  Your third paragraph below should read "...makes D far and away the best language for writing reliable, robust applications. ..."  "Systems" programming to me means conjures up things like device drivers, compilers and linkers.

Your comments (here and on the website) about unit tests and design-by-contract are valid for ALL types of applications, and D by and large looks to be well on it's way to having the makings of a great general-purpose programming language.

   Dan

"Walter" <walter@digitalmars.com> wrote in message news:a9381e$jin$1@digitaldaemon.com...
>
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB50E8C.EA1F02D5@deming-os.org...
> > Pavel Minayev wrote:
> > > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB50812.32369985@deming-os.org...
> > > > Ok, another question...as I read the specs, unittest() sounded like
it
> > > > only was available as a member function of classes.  But adi.d has a bunch of them out at module level.  I presume that this means that
all
> > > > of them are run automatically as the unit test of the module.  If
this
> > > > is correct, the QA dept should have noted that in the spec ;-)
> > > In fact, unittest is module-level function. See string.d, regexp.d...
> > Yeah, it makes sense.  But it should be in the docs.  Also, the docs
> should
> > note that one module can have multiple unittests.
>
> Bruce Eckel originally pointed out that D needed language support for unit testing. He showed me some of the kludgy ways it was done in other
languages
> that weren't accommodating of the concept. Once I implemented it and tried it out, my thinking on how it should be used evolved and its role
expanded.
> Unit testing has in my mind risen to become a main feature of D. For
library
> functions it works out great, serving both to guarantee that the functions actually work and to illustrate how to use the functions.
>
> Consider the many C++ library and application code bases out there for download on the web. How much of it comes with *any* verification tests at all, let alone unit testing? Less than 1%? The usual practice is if it compiles, we assume it works. And we wonder if the warnings the compiler spit out in the process are real bugs or just an irrelevancy.
>
> Along with design by contract, unit testing makes D far and away the best language for writing reliable, robust systems applications. Nearly every
one
> of those library routines had at least one bug exposed by the unit
testing.
> Unit testing also gives us a quick-and-dirty estimate of the quality of
some
> unknown piece of D code dropped in our laps - if it has no unit tests and
no
> contracts, it's unacceptable.
>
> (I'm going to regret making that last statement!)
>
>
>

"J. Daniel Smith" wrote:

> IMHO, you really need to stop focusing on the "system" aspects of D.  Your third paragraph below should read "...makes D far and away the best language for writing reliable, robust applications. ..."  "Systems" programming to me means conjures up things like device drivers, compilers and linkers.
>
> Your comments (here and on the website) about unit tests and design-by-contract are valid for ALL types of applications, and D by and large looks to be well on it's way to having the makings of a great general-purpose programming language.

I agree (about the terminology).  I think "general-purpose" is exactly what Walter is getting at - unlike some other languages (like Java, BASIC, or whatever), D is useful for BOTH applications AND low-level drivers and kernel programming.  However, the term "systems applications" conjures up (in my mind) an explicit focus on low-level stuff.

Frankly, I'm excited about using D for all my applications...and somebody's going to have start porting the Linux kernel over ;-)  (Pavel, you seem the most avid porter of all of us...there's a project for you!)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB5BEFA.8355ACC@deming-os.org...

> Frankly, I'm excited about using D for all my applications...and
somebody's
> going to have start porting the Linux kernel over ;-)  (Pavel, you seem
the most
> avid porter of all of us...there's a project for you!)

Well, since I don't like Linux, I guess it's not a project for me... =)

"J. Daniel Smith" <j_daniel_smith@HoTMaiL.com> wrote in message news:a941gl$1efo$1@digitaldaemon.com...
> IMHO, you really need to stop focusing on the "system" aspects of D.  Your third paragraph below should read "...makes D far and away the best
language
> for writing reliable, robust applications. ..."  "Systems" programming to
me
> means conjures up things like device drivers, compilers and linkers.
>
> Your comments (here and on the website) about unit tests and design-by-contract are valid for ALL types of applications, and D by and large looks to be well on it's way to having the makings of a great general-purpose programming language.

Your points are well taken. My emphasis on "systems" programming was an attempt to distinguish D from so-called "web" languages like C#, Java, Javascript, etc., which compile to a bytecode that is then interpreted/compiled in an attempt to have portable executables (as opposed to portable source).

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB5BEFA.8355ACC@deming-os.org...

snip

>
> Frankly, I'm excited about using D for all my applications...and
somebody's
> going to have start porting the Linux kernel over ;-)

It isn't obvious, at least to me :-), that a garbage collected language will work for an operating system.  I know there has been much gnashing of teeth over Java's GC system among the people who want to use JAVA for embedded applications.  I don't know all of the details, but much of it revolves arount having the system decide to do GC at inopportune times, like when a response is required in reeal time to some external event.





(Pavel, you seem the most
> avid porter of all of us...there's a project for you!)
>
> --
> The Villagers are Online! villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
>
>