www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - unofficial D wish list

reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
I have move all the wish items form the old eigenpoll 
to a new one and I hope it can serve as an unofficial D wish list.

http://www.all-technology.com/eigenpolls/dwishlist/

Knud
Mar 02 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Knud Sørensen wrote:

 I have move all the wish items form the old eigenpoll 
 to a new one and I hope it can serve as an unofficial D wish list.
 
 http://www.all-technology.com/eigenpolls/dwishlist/


We already have a more comprehensive unofficial D wish list:

http://www.wikiservice.at/wiki4d/wiki.cgi?FeatureRequestList

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 03 2005
parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Thu, 03 Mar 2005 15:27:56 +0000, Stewart Gordon wrote:



 We already have a more comprehensive unofficial D wish list:
 
 http://www.wikiservice.at/wiki4d/wiki.cgi?FeatureRequestList
 


Nice list!

The problem is that you can't see how strong the wish is.
So, there is no way to see if it is just a crazy idea or something 
people really want.

Knud
Mar 03 2005
next sibling parent "Lynn Allan" <l_d_allan adelphia.net> writes:
 The problem is that you can't see how strong the wish is.
 So, there is no way to see if it is just a crazy idea or something
 people really want.


FWIW:
The open source Audacity project has an interesting "voting" page for
feature requests

http://audacityteam.org/FeatureRequest.php
Mar 03 2005
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Knud Sørensen wrote:

 On Thu, 03 Mar 2005 15:27:56 +0000, Stewart Gordon wrote:
 

 We already have a more comprehensive unofficial D wish list:
 
 http://www.wikiservice.at/wiki4d/wiki.cgi?FeatureRequestList


 
 Nice list!
 
 The problem is that you can't see how strong the wish is.
 So, there is no way to see if it is just a crazy idea or something 
 people really want.


Your poll has a few problems:

1. No means is provided of modifying a feature proposal or even adding 
comments.  So if someone feels that

- a feature's description is far too content-free to vote on
- the specifics want reworking a bit
- a proposal consists of two somewhat different issues, and they need to 
be separated

then there's no way to propose any change or clarification.

For example, some of my comments would be to the effect of:

(a) A few of the descriptions effectively do nothing but repeat the 
title of the proposal, and provide none of the necessary information to 
know what really is being proposed.

(b) The proposed "!new" syntax is redundant with "null".  Though 
personally, that whole proposal would go on my bad idea list....

(c) If we're going to enforce black-box unit testing, then the syntactic 
salt for white-box tests ought to be in the code, rather than on the 
command line.

(d) The description of "Array initialization/literals" covers only 
initialization, not literals (but I agree that they should be two
separate proposals)

(e) "Javadoc documentation" isn't really a language feature, but 
something that can be developed separately from the language and 
compiler.  So is it really on-topic here?

2. No semantics of not ranking a given proposal are clarified.  People 
could use it to mean:
- I'm just not sure how important this feature is
- I don't care for it
- I think it's a bad idea
- One of the issues of point 1 is making me not sure about it
- This proposal wasn't listed when I voted

and you won't be sure what the abstainers are meaning.

3. What if someone wants to change his/her/its mind; moreover, revote 
now that the list has grown?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 03 2005
parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Thu, 03 Mar 2005 17:01:38 +0000, Stewart Gordon wrote:


 Knud Sørensen wrote:

 On Thu, 03 Mar 2005 15:27:56 +0000, Stewart Gordon wrote:
 

 We already have a more comprehensive unofficial D wish list:
 
 http://www.wikiservice.at/wiki4d/wiki.cgi?FeatureRequestList


 
 Nice list!
 
 The problem is that you can't see how strong the wish is.
 So, there is no way to see if it is just a crazy idea or something 
 people really want.


 
 Your poll has a few problems:
 
 1. No means is provided of modifying a feature proposal or even adding 
 comments.  So if someone feels that
 
 - a feature's description is far too content-free to vote on
 - the specifics want reworking a bit
 - a proposal consists of two somewhat different issues, and they need to 
 be separated
 
 then there's no way to propose any change or clarification.


My suggestion is that you make a better suggestion and post it !
May the best suggestion win ;-)
 
I will then make some clean up, if the is doublets.


 For example, some of my comments would be to the effect of:
 
 (a) A few of the descriptions effectively do nothing but repeat the 
 title of the proposal, and provide none of the necessary information to 
 know what really is being proposed.



 (b) The proposed "!new" syntax is redundant with "null".  Though 
 personally, that whole proposal would go on my bad idea list....


agree with !new, like the auto new stuff.
 

 (c) If we're going to enforce black-box unit testing, then the syntactic 
 salt for tests ought to be in the code, rather than on the 
 command line.


No, consider a team where one developer cheat and compile with
--allow-white-box, then the other developers will notice as soon
they compile the code.
If you hide the white-box stuff in the code they might never know
and we would not be enforcing black-box testing would we ??


 (d) The description of "Array initialization/literals" covers only 
 initialization, not literals (but I agree that they should be two
 separate proposals)
 
 (e) "Javadoc documentation" isn't really a language feature, but 
 something that can be developed separately from the language and 
 compiler.  So is it really on-topic here?



 2. No semantics of not ranking a given proposal are clarified.  People 
 could use it to mean:
 - I'm just not sure how important this feature is
 - I don't care for it
 - I think it's a bad idea
 - One of the issues of point 1 is making me not sure about it
 - This proposal wasn't listed when I voted


Agree, I will add something about it in the weekend.


 and you won't be sure what the abstainers are meaning.
 
 3. What if someone wants to change his/her/its mind; moreover, revote 
 now that the list has grown?
Mar 03 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Knud Sørensen wrote:
<snip>

 (c) If we're going to enforce black-box unit testing, then the 
 syntactic salt for tests ought to be in the code, rather than on 
 the command line.


 
 No, consider a team where one developer cheat and compile with 
 --allow-white-box, then the other developers will notice as soon they 
 compile the code.


If by your conception using --allow-white-box is cheating, why allow it 
at all?


 If you hide the white-box stuff in the code they might never know and
 we would not be enforcing black-box testing would we ??


<snip>

What have you against white-box tests?  I.e. if someone _wants_ to put 
in some code to test the internal workings, why give the outside user 
the trouble of knowing that they have to compile with --allow-white-box? 
  My point is that there should be a notation to separate the white-box 
tests (to check that it works from the developer's point of view) from 
the black-box tests (to check that it works from the user's point of view).

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.
Mar 04 2005
parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Fri, 04 Mar 2005 10:33:21 +0000, Stewart Gordon wrote:


 Knud Sørensen wrote:
 <snip>

 (c) If we're going to enforce black-box unit testing, then the 
 syntactic salt for tests ought to be in the code, rather than on 
 the command line.


 
 No, consider a team where one developer cheat and compile with 
 --allow-white-box, then the other developers will notice as soon they 
 compile the code.


 
 If by your conception using --allow-white-box is cheating, why allow it 
 at all?


If the team have committed to black-box unit testing then white box
unit testing is cheating.

But it takes time to learn how to write good testable code,
so a newbie might like to use --allow-white-box.



 If you hide the white-box stuff in the code they might never know and
 we would not be enforcing black-box testing would we ??


 <snip>
 
 What have you against white-box tests?  


I would rather tell you why I like black box unit testing.

The short answer is that it encourage you to write good code.

The long is 
1) Decouples the unit test from the class implementation.
So, You don't have to change the unit test when your 
change the class implementation only when you change the interface.

and when used with 100% unit test coverage.

2) Eliminate dead code from the class.
Dead code can't be test with black box testing
so it shows up in the coverage analyses.

3) Find code with hidden dependencies.
This is also hard to black box test 
and will show up in the coverage analyses.
Here we need to use dependency injection.

etc.. I am sure that the is many more.



  I.e. if someone _wants_ to put 
 in some code to test the internal workings, why give the outside user 
 the trouble of knowing that they have to compile with ? 


When an developer wants to use white box unit testing for internal
working it is almost always a sign that there is some code that 
should be refactored to another class and/or tested with mock obejcts.

Often the developer have never heard of mock objects and/or dependency
injection.

That it is troublesome to tell the user to compile with --allow-white-box
will only encourage the developer to learn about better ways to test the
code.


   My point is that there should be a notation to separate the white-box
 tests (to check that it works from the developer's point of view) from
 the black-box tests (to check that it works from the user's point of
 view).


Let make it clear what we mean by developer and user.

We have the application (app) level and the class level.
Let call them app user, app developer and class user and class developer.

Let say that the app developer is also the class user but not the class
developer. 

An app developer would call the functional test
for black box testing and unit testing for write box testing.

An class developer would call 'black box' unit testing for black box
testing and test where you compile test code in, use debugger or valgrind
for white box testing.
  
When I write a application I split it in 5 layers.
Interface layer,
application layer 
domain layer 
technical layer
platform layer.

Then when I write functional test I only "talk to" the interface layer.
If I wrote a functional test which depended on a matrix library from the
technical layer, then I would have to rewrite the test if I decided 
to use another matrix library and I would be testing the implementation 
not the functionality.

In the same way with black and write unit test.
Blacks test the functionality of the class
while white test the implementation directly.

So, allowing white unit tests make the code hard to refactor and maintain.
Mar 04 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Knud Sørensen wrote:
<snip>

 When an developer wants to use white box unit testing for internal
 working it is almost always a sign that there is some code that 
 should be refactored to another class and/or tested with mock obejcts.


To me, it's a sign that the user wants to test some aspects of the 
internal workings when they might expose bugs to the effect that some 
cases (missed by the black-box tests) might not work.  Or maintain 
checks that the workings are working before writing more public functions.

<snip>

 In the same way with black and write unit test.
 Blacks test the functionality of the class
 while white test the implementation directly.
 
 So, allowing white unit tests make the code hard to refactor and maintain.   


If they want to refactor, it goes without saying that this would include 
refactoring the white-box unit tests as appropriate.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 04 2005
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
In article <pan.2005.03.03.16.23.03.684303 sneakemail.com>,
=?iso-8859-1?q?Knud_S=F8rensen?= says...

On Thu, 03 Mar 2005 15:27:56 +0000, Stewart Gordon wrote:



 We already have a more comprehensive unofficial D wish list:
 
 http://www.wikiservice.at/wiki4d/wiki.cgi?FeatureRequestList
 


Nice list!

The problem is that you can't see how strong the wish is.
So, there is no way to see if it is just a crazy idea or something 
people really want.

Knud


I suspect that Walter is more persuaded by one strong argument in this newsgroup
group than ten "me-too" votes on a wish list.

jcc7
Mar 03 2005
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
J C Calvarese wrote:

 
 
 I suspect that Walter is more persuaded by one strong argument in this
newsgroup
 group than ten "me-too" votes on a wish list.
 
 jcc7


Oftn, even strong argument doesn't have it's sway with Walter. ;-)
Mar 03 2005
prev sibling parent =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Thu, 03 Mar 2005 18:10:21 +0000, J C Calvarese wrote:


 In article <pan.2005.03.03.16.23.03.684303 sneakemail.com>,
 =?iso-8859-1?q?Knud_S=F8rensen?= says...

On Thu, 03 Mar 2005 15:27:56 +0000, Stewart Gordon wrote:



 We already have a more comprehensive unofficial D wish list:
 
 http://www.wikiservice.at/wiki4d/wiki.cgi?FeatureRequestList
 


Nice list!

The problem is that you can't see how strong the wish is.
So, there is no way to see if it is just a crazy idea or something 
people really want.

Knud


 
 I suspect that Walter is more persuaded by one strong argument in this
newsgroup
 group than ten "me-too" votes on a wish list.


I think we should leave the decision to Walter!

This newsgroup get more and more traffic as D spreads 
and would we rather that Walter spends time improving D 
or that He read every post on this newsgroup ???

The wish list is just a way to collect the ideas 
from the group, so that one can get a fast overview 
when needed.
 


 jcc7
Mar 03 2005