September 13, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | In article <cht9gl$20m8$1@digitaldaemon.com>, Walter says... > >So I'd like to kick off this thread as an opportunity for all to post their two Most Important Issues for D with respect to getting 1.0 done. By MIID, I mean pragmatic things like: > >1) compiler bugs >2) language shortcomings with no reasonable workarounds >3) issues that are fundamentally blocking projects from using or proceeding >with D >4) severe library faults Memory management issues - specifically, the interaction of the garbage collector with DLLs and the absence of C++-style memory management. I shall be more specific. (1) Suppose a class A has its own custom allocator/deallocator. Suppose it also has a destructor. I want to be able to call the destructor (~this()) /without/ also calling the deallocator. I also want to be able to call the deallocator (the delete override) /without/ also calling the destructor. Both of these things are possible in C++, but not in D. Same goes for allocation versus construction. (2) I want to be able to globally (not just per-class) override new. For example, I want to be able to do: # int[] array = new(myGlobalAllocator) array[n]; (3) And (most importantly) I want the garbage collector's memory-tracking mechanism to /notify me/ when the memory I've allocated via my custom allocator is no longer referenced. With these modifications in place, all memory allocation issues, including garbage collection across DLL boundaries; plugging in an alternative garbage collector; secure wiping of sensitive data; super-fast allocation/deallocation of small objects; etc., would become immediately and simply solvable. Okay, so that's three things, not two, but they go together, and missing any one of them out seemed a bit dumb. Jill |
September 13, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | Walter wrote: <snip> > So I'd like to kick off this thread as an opportunity for all to post their > two Most Important Issues for D with respect to getting 1.0 done. <snip> 1. A complete spec. 2. Complete functionality in line with the spec. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit. |
September 13, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sai | Sai wrote: <snip> > 3. Documentation is very bad. I think any powerful API is useless > unless it is well documented. Lacking of "Search" facility or "Index" in D documentation is a huge discouraging factor. <snip> Doesn't your web browser allow you to search within a page? To me, the trouble with Phobos documentation is the amount of Phobos that is still undocumented. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit. |
September 13, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Swieton | In article <pan.2004.09.11.20.54.46.684151@swieton.net>, Mike Swieton says... > >I'm not sure if this is a shortcoming, or just a feature request, but I'll mention it again: D's unit test facility is not usable for test driven development (because it's unnecessarily difficult to run a subset of tests) How narrow a subset do you need? I have set up my makefile to make a stand alone program of each module, called ut_modname, which does nothing but run the module unit tests. > or for automated builds (because a single failure will halt >execution of the test suite). Can't you get around this by writing errors to stdout, stderr or a log file instead of using asserts? Nick |
September 13, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick | In article <ci4oks$2rt0$1@digitaldaemon.com>, Nick says... > >In article <pan.2004.09.11.20.54.46.684151@swieton.net>, Mike Swieton says... >> >>I'm not sure if this is a shortcoming, or just a feature request, but I'll mention it again: D's unit test facility is not usable for test driven development (because it's unnecessarily difficult to run a subset of tests) > >How narrow a subset do you need? I have set up my makefile to make a stand alone program of each module, called ut_modname, which does nothing but run the module unit tests. > >> or for automated builds (because a single failure will halt >>execution of the test suite). > >Can't you get around this by writing errors to stdout, stderr or a log file instead of using asserts? > No, not and have it still be D's unit test facility. Sure, I can write CppUnit in D, and use that. But that's hardly means that D's unit test feature works. Just because I can implement test selection in a Makefile doesn't mean that it's a solution. It's only a workaround. Good unit test suites which meet all of my criteria can be made and written in D. But that can be done in assembly and befunge too. I am saying that if I want to do this in D, I have to actively fight 'features' of D's unit testing. Therefore, D does not have a sufficient unit test facility. |
September 13, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Swieton | In article <ci4q6p$he$1@digitaldaemon.com>, Mike Swieton says... > >No, not and have it still be D's unit test facility. Sure, I can write CppUnit >in D, and use that. But that's >hardly means that D's unit test feature works. Just because I can implement test >selection in a Makefile >doesn't mean that it's a solution. It's only a workaround. Point taken. >Good unit test suites which meet all of my criteria can be made and written in >D. But that can be done >in assembly and befunge too. I am saying that if I want to do this in D, I have >to actively fight 'features' >of D's unit testing. Therefore, D does not have a sufficient unit test facility. Ok. Do you (or anyone else) have any specific suggestions as to how to improve the D unit test system so it will meet your criteria? I admit I'm pretty clueless about this. Nick |
September 13, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | Walter wrote: > So I'd like to kick off this thread as an opportunity for all to post their two Most Important Issues for D with respect to getting 1.0 done. By MIID, I mean pragmatic things like: > > 1) compiler bugs > 2) language shortcomings with no reasonable workarounds > 3) issues that are fundamentally blocking projects from using or proceeding > with D > 4) severe library faults > > I don't mean things like: > > 1) D 2.0 issues > 2) feature proposals like "It would be nice if ..." > 3) minor irritants > 4) philosophical issues > 5) issues that have been beaten to death already <g> It might not exactly follow your guidelines, but I would add: static initialization of dynamic arrays and hashes (assoziative arrays). In Perl you write just my @array=( 1, 12, 333, -4, 5); my %hash=( 'darkred' => '#bb0000', 'red' => '#ff0000', 'lightred' => '#ffcccc'); and this makes array and hashes really a pleasure to use. Of course, the exact syntax for this isn't important. -- Helmut Leitner leitner@hls.via.at Graz, Austria www.hls-software.com |
September 13, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick | On Mon, 13 Sep 2004 19:46:56 +0000, Nick wrote:
> Ok. Do you (or anyone else) have any specific suggestions as to how to improve the D unit test system so it will meet your criteria? I admit I'm pretty clueless about this.
>
> Nick
These are my requirements (in no order):
1: Test isolation. I should be able to have a single test failure abort only
that test.
Rationale: Automated tests. At work, we have one particular product who's
test suite takes hours to run fully. Others merely take tens of minutes. I
run it over night, and I want to come in in the morning and see a complete
report of the results, not just the first failure.
2: Test selection. I should be able to select a subset of tests
programatically.
Rationale: This stems from the above: with a large test suite, I should be
able to run just a few. The 'programatically' part is essentially
philosophical: managing the test suite is the job of the test framework, not
the build system.
2: Separate tests from application. I should be able to run the tests without
running the application.
Rationale: A unit test for a single function doesn't require the entire app.
Also, the startup of a large program may be time consuming, resource
intensive, or interactive. Again, this is largely ideological: the tests and
the app are simply not the same thing. It is illogical to run a batch of
tests overnight, and come back to a running app in the morning. Why are the
two activities connected?
3: Test reports. I should be able to generate some sort of report about which
tests failed, and why.
Rationale: Currently, if there's a failure, testing terminates. However, if
I want to run a batch of 5000 tests, and 300 fail, it's impractical for me
to not have a file documenting it.
4: Useful asserts. I want an assertEquals. I want an assert with a message.
Rationale: I'm lazy. Also, I want a message because assert(x < 3 && x > 1)
doesn't really *mean* "assert that x is between 1 and 3". It means something
like "assert that x is within the range valid for brake forces".
Walter has said that the line number output is enough, but that's gets less
useful for unit test suites because if I get a test report of 300 failures,
I want to look at the report and see why it failed. I don't want to see 300
line numbers.
5: Setup/teardown methods.
Rationale: it is tremendously useful to be able to run some setup/cleanup
code before/after tests run, to ensure a clean environment. This is
basically required when the code involves something persistent that needs
the state to be reset, such as a hardware device or database.
Now, this is how I want things to behave. This doesn't necessarily mean that it needs to be implemented in the language itself, only that it should be able to be done without replacing D's unit testing.
My suggestions to accomplish the above:
- Change assert to be a normal function that can be overridden, and have it
thrown an exception. That is, make it Java-like. This will require some
magic to continue to let assertions have line numbers and file names. This
addresses #4, and #1.
- Separate tests into actual functions, named, and expose them somehow (such
as an AA).
If these two are done, a library could be written on top of D allowing D to keep the current behavior (test fatality would stay because the exception would be uncaught, and test selection would follow the current scheme). At the same time, a library could allow you to select which tests to run, handle all the logging, etc.
I don't care if this is how it's solved, but right now I don't feel that D can really advertise built in unit testing. It simply isn't there yet.
What I object to now is that to get the behavior I want (which is required for
TDD), I need to throw away or work around D's built in unit testing - one of
my (theoretically) favorite D features.
Mike Swieton
__
If the government wants us to respect the law, they should set a better
example.
|
September 14, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Helmut Leitner | Helmut Leitner wrote: <snip> > It might not exactly follow your guidelines, but I would add: > static initialization of dynamic arrays and hashes (assoziative arrays). > > In Perl you write just > > my @array=( 1, 12, 333, -4, 5); > my %hash=( 'darkred' => '#bb0000', 'red' => '#ff0000', 'lightred' => '#ffcccc'); > > and this makes array and hashes really a pleasure to use. > Of course, the exact syntax for this isn't important. Presumably they'd take on the exact same syntax we already have for static initialisation of static arrays. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit. |
September 14, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | In article <ci3jv1$10v8$1@digitaldaemon.com>, Arcane Jill says... I want to change my mind about what I consider the most important and urgent impediment to writing code in D. Instead of my previous suggestion (GC/DLL/memory management issues), I now want to vote instead for DEBUGGING INFORMATION. I can use D with Visual Studio to a limited extent, but it won't expand non-primitive D types, and -- /most importantly/ -- if you try to step into a template class or function, the source-code view jumps to COMPLETELY THE WRONG PLACE. Is this hindering development? Yes, absolutely. In fact, it's the sole reason I'm not using templates yet. Jill |
Copyright © 1999-2021 by the D Language Foundation