March 26, 2004
On Thu, 25 Mar 2004 20:42:53 +0100, Ilya Minkov wrote:

> I would like to throw in a few ideas for discussion. Please note that these are to be seen separately from each other because some of them don't combine or combinations don't make sense.
> 
> * Assert is overrided roughly the same way as a GC. That is, by assigning a new assert at the run time rather than at link time, since the second poses severe problems for no gain.

I think assert should be customizable, but I really don't know the best way of doing so.

> * An exception object for assert, which needs to have such a
> constructor, or simply a function, which gets an info-string, line and
> filename. The info-string can be filled by a compiler in one of many
> manners such as:
> - null, e.g. for executables, where there is no debugging information or
> source could not be found;
> - source line, if compiled with debugging information and source is
> available;
> - custom string if supplied in assertion?

I dislike this info-string trick, because it puts more special-case handling in the compiler. I think that this is more special-purpose of an application. (*usable* only by assert, whereas the change I suggested would be *useful* only for assert. I think the distinction is important.)

> * Custom string is not necessary when source is output, because assert(qexpression && "Error Description"); works as well, because string literal is always true.

It's a hack. Even if it becomes a D idiom, it's still a hack.

> * Separate asserts for equality, nonequality, and so on are not requiered. Let automatic conversions to boolean do their job. Assignment in assert should be forbidden, just to make sure someone doesn't make a silly typing mistake. The test for object existance is then assert(object) as it is now. In Java, such separate asserts do make sense due to other shortcomings, but in D (operator overloads, and so on) they don't.

Not strictly true. Consider that C++ unit test frameworks usually add these assertions. The primary thing that an assertEquals method gives you is good output: it automatically constructs an error message with your got and expected values, so you don't need to do it yourself.

> * An assertion function needs not have the boolean parameter at all. It should be called by the compiler only if the assertion has failed.

An interesting proposal, but I think that adds more magic than is necessary.

> * A simple tool can generate programs for automatic tests from the source. This is not a consern of the language, and it's probably better done with a tool than with a library. And i don't see why there should be a preferance of a library over a tool, if a tool is open and only requieres D standard libraries. The one trying to write such a tool can make use of compiler sources for fast parsing or port ANTLR to do D output and write a (partial?) D grammar for it.

I prefer a library over a tool for several reasons:

	- D's most unique feature is built in unit testing. It shouldn't need a
	  tool beyond the compiler to use the features of the language. A library
	  is a lot closer to the language.
	- A tool adds an extra step and will make builds more complex.

> * Assert function in fact need not be changable at all, it is enough for it to throw an error-like exception object which would contain all the information you may need (source snippet, module, line), and do nothing else. Then, in the program top level you can decide what to do with it. For example, you can display the message in a pop-up window, or onto a console, or log it in a file, from there. The start-up code should simply output them to stderr.

The disadvantage of this approach is that your exception object is always the same, meaning you may not have a goot way of

> * If the user thinks some assertions are getting too heavy for him, he should make use of the version statement.

I'm not clear on what you mean by this: could you clarify it? Why would the assertions be too heavy, and how would conditional compilation help it?

> * Heavy changes on the language should not be taken now! The changes, if taken now, should be very simple and to prevent breaking code by changes requiered further on by 2.0! So consider a "partial" change which would give you a way of enhancement in further versions.

I think the unit test shortcomings in D should be addressed. If Walter wants to do it in 2.0, fine ;) But I do think it should be addressed.

Mike Swieton
__
You can have peace. Or you can have freedom. Don't ever count on having
both at once.
	- Lazarus Long (Robert A. Heinlein)

March 26, 2004
>Assignment in assert should be forbidden, just to make sure someone doesn't make a silly typing mistake. >

good suggestion

>
>* A simple tool can generate programs for automatic tests from the source. This is not a consern of the language, and it's probably better done with a tool than with a library. And i don't see why there should be a preferance of a library over a tool, if a tool is open and only requieres D standard libraries. The one trying to write such a tool can make use of compiler sources for fast parsing or port ANTLR to do D output and write a (partial?) D grammar for it.

agreed
actually this would help generate a test framework, the test cases still have be
written.

The D unittest facility still needs a test driver like JUnit to cover all the desired test cases for a module since multiple instances of the class under test might have to be created or a module may only consist of related functions such as a math module.

Don't mess up the language by overdoing the built-in unittest facility.



1 2
Next ›   Last »