www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unofficial wish list status.

reply 12tkvvb02 sneakemail.com writes:
Hi

This is the monthly status for the unofficial d wish list: 
http://all-technology.com/eigenpolls/dwishlist/

Right now the wish list looks like this:

0.565  5  Auto new-ing of classes
0.528  6  unit test after compilation
0.507  6  array initialization/literals
0.501  6  Reflection API
0.487  3  Compiler values
0.407  4  vectorization
0.396  4  black box unit testing
0.394  4  Unit test isolation 
0.375  4  unit test & code separation
0.33  3  Array masking
0.315  4  unit test coverage 
0.263  4  Unit test measurements
0.202  2  Posix threads support native
0.187  2  Javadoc documentation
0.187  3  Faster GC
Mar 24 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
<12tkvvb02 sneakemail.com> wrote in message 
news:d1uve0$2ca$1 digitaldaemon.com...

 Hi

 This is the monthly status for the unofficial d wish list:
 http://all-technology.com/eigenpolls/dwishlist/

 Right now the wish list looks like this:

 0.565  5  Auto new-ing of classes


wow - I'm surprised this is popular (though I don't know how many people 
have voted or how often). For those who didn't follow the link, here's the 
description of auto new'ing:
Foo A;
is shorthand for Foo A = new Foo and
Foo A = !new
would be the way of initializing to null.

I'd be very surprised if Walter changes the language to do that. The current 
system is much better.
Mar 24 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 24 Mar 2005 17:58:31 -0500, Ben Hinkle wrote:


 <12tkvvb02 sneakemail.com> wrote in message 
 news:d1uve0$2ca$1 digitaldaemon.com...

 Hi

 This is the monthly status for the unofficial d wish list:
 http://all-technology.com/eigenpolls/dwishlist/

 Right now the wish list looks like this:

 0.565  5  Auto new-ing of classes


 
 wow - I'm surprised this is popular (though I don't know how many people 
 have voted or how often). For those who didn't follow the link, here's the 
 description of auto new'ing:
 Foo A;
 is shorthand for Foo A = new Foo and
 Foo A = !new
 would be the way of initializing to null.
 
 I'd be very surprised if Walter changes the language to do that. The current 
 system is much better.


I submitted this one. There is further discussion at ...

http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/AutoNewingOfClasses


-- 
Derek Parnell
Melbourne, Australia
25/03/2005 10:17:37 AM
Mar 24 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1hyzck675ctcf$.14kdoa1p26fdc$.dlg 40tude.net...

 On Thu, 24 Mar 2005 17:58:31 -0500, Ben Hinkle wrote:


 <12tkvvb02 sneakemail.com> wrote in message
 news:d1uve0$2ca$1 digitaldaemon.com...

 Hi

 This is the monthly status for the unofficial d wish list:
 http://all-technology.com/eigenpolls/dwishlist/

 Right now the wish list looks like this:

 0.565  5  Auto new-ing of classes


 I'd be very surprised if Walter changes the language to do that. The 
 current
 system is much better.


 I submitted this one. There is further discussion at ...

 http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/AutoNewingOfClasses


The =null makes more sense than the =!new. How did it turn into !new on the 
eigenpoll? oh well. But even with =null I would be surprised if Walter goes 
for it. The proposal doesn't feel right to me for two reasons: 1) an 
expensive operation like "new" shouldn't be implicit, and 2) it would mean 
the code
Foo a;
a = ...;
is different than
Foo a = ...;

Even though C++ distinguishes between initialization and assignment I don't 
D should go down that road.
Mar 24 2005
next sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
 

 The =null makes more sense than the =!new. 
 How did it turn into !new on the eigenpoll? oh well. 


Apparently someone posted it with !new. 
The question is how long it will take 
for someone to post a new suggestion with null.

But I can see why it is popular.

When coming from C++ it seems strange
that you should write the class name twice to get an element.
C++: MyClassName aElement(...);
D:   MyClassName aElement= new MyClassName(...);

That is almost twice as much typing to do the same thing,
and that is every time you need an element of a class.

To go easy on exiting code the compiler could be updated in stages.

1) Warn for implicit null code like
MyClassName nullElement; 

2) Disallow implicit null and enforce 
MyClassName nullElement = null;  
This will force all existing code to be updated.

3) After a while change 
MyClassName aElement;
to implicit mean  
MyClassName aElement = new MyClassName;


 But even with =null I would be surprised if Walter goes 
 for it. The proposal doesn't feel right to me for two reasons: 1) an 
 expensive operation like "new" shouldn't be implicit, 


Not even if you need it anyway 99.99% of the time ?


 and 2) it would mean 
 the code
 Foo a;
 a = ...;
 is different than
 Foo a = ...; 
 Even though C++ distinguishes between initialization and assignment I don't 
 D should go down that road.
Mar 25 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Knud Sørensen wrote:


 But I can see why it is popular.
 
 When coming from C++ it seems strange
 that you should write the class name twice to get an element.
 C++: MyClassName aElement(...);
 D:   MyClassName aElement= new MyClassName(...);


This is because D (just like Java) has eliminated both
special syntax for pointers/references and stack objects ?

C++:  MyClassName *aElement; // some fun random value
D:    MyClassName aElement; // always null

Both: aElement = new MyClassName(...);

I can see how it get's a bit tricky at first, though...
(when coming from C++ and used to non-reference classes)


 3) After a while change 
 MyClassName aElement;
 to implicit mean  
 MyClassName aElement = new MyClassName;
 

But even with =null I would be surprised if Walter goes 
for it. The proposal doesn't feel right to me for two reasons: 1) an 
expensive operation like "new" shouldn't be implicit, 




Simple objects like ints and structs are different
from references and pointers, as well ? But since the
default (.init) values seems messed up anyway, like
with characters and floating point values, I do *fear*
that one has to initialize everything explicitly...

Who knows, maybe this will change in a future D version ?
(then all now-null references will allocate Objects instead,
and the current code will start behaving somewhat differently...)

But I hope not. (being used to Java)

--anders
Mar 25 2005
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 25 Mar 2005 11:55:41 +0100, Knud Sørensen  
<12tkvvb02 sneakemail.com> wrote:

 When coming from C++ it seems strange
 that you should write the class name twice to get an element.
 C++: MyClassName aElement(...);
 D:   MyClassName aElement= new MyClassName(...);

 That is almost twice as much typing to do the same thing,
 and that is every time you need an element of a class.


If anything, I would like this idea better..

MyClassName a;       //a is null
MyClassName a();     //same as MyClassName a = new MyClassName();
MyClassName a(1,2);  //same as MyClassName a = new MyClassName(1,2);
MyClassName a = new MyClassName(1,2,3);  //obvious :)

Though, and here's the kicker, the a() example looks like a class created  
on the stack, right? as in C++, and it's not.

Regan
Mar 25 2005
next sibling parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
DAMN! I just refreshed before posting my response, and refreshed after 
posting and read this! Great idea!

Lionello.

"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsn62vgol23k2f5 nrage.netwin.co.nz...

 On Fri, 25 Mar 2005 11:55:41 +0100, Knud Sørensen 
 <12tkvvb02 sneakemail.com> wrote:

 When coming from C++ it seems strange
 that you should write the class name twice to get an element.
 C++: MyClassName aElement(...);
 D:   MyClassName aElement= new MyClassName(...);

 That is almost twice as much typing to do the same thing,
 and that is every time you need an element of a class.


 If anything, I would like this idea better..

 MyClassName a;       //a is null
 MyClassName a();     //same as MyClassName a = new MyClassName();
 MyClassName a(1,2);  //same as MyClassName a = new MyClassName(1,2);
 MyClassName a = new MyClassName(1,2,3);  //obvious :)

 Though, and here's the kicker, the a() example looks like a class created 
 on the stack, right? as in C++, and it's not.

 Regan
Mar 25 2005
prev sibling parent =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
I like this idea!
I have added it as "short syntax for new" to the wish list at:

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

 

 MyClassName a;       //a is null
 MyClassName a();     //same as MyClassName a = new MyClassName();
 MyClassName a(1,2);  //same as MyClassName a = new MyClassName(1,2);
 MyClassName a = new MyClassName(1,2,3);  //obvious :)
 
 Though, and here's the kicker, the a() example looks like a class created  
 on the stack, right? as in C++, and it's not.
 
 Regan
Mar 25 2005
prev sibling parent "John C" <johnch_atms hotmail.com> writes:
"Knud Sørensen" <12tkvvb02 sneakemail.com> wrote in message 
news:pan.2005.03.25.10.55.40.584375 sneakemail.com...

 The =null makes more sense than the =!new.
 How did it turn into !new on the eigenpoll? oh well.


 Apparently someone posted it with !new.
 The question is how long it will take
 for someone to post a new suggestion with null.

 But I can see why it is popular.

 When coming from C++ it seems strange
 that you should write the class name twice to get an element.
 C++: MyClassName aElement(...);
 D:   MyClassName aElement= new MyClassName(...);


This argument doesn't hold: you can't say it's to make things simpler for 
C++ programmers and then give them completely different behaviour. In C++, 
that syntax creates an object on the stack; in the proposal for D, it still 
creates an object on the heap.

From what I've seen of this proposal and the follow-up threads, it's 
actually complicating matters and would require a lot of special-casing.


 That is almost twice as much typing to do the same thing,
 and that is every time you need an element of a class.

 To go easy on exiting code the compiler could be updated in stages.

 1) Warn for implicit null code like
 MyClassName nullElement;

 2) Disallow implicit null and enforce
 MyClassName nullElement = null;
 This will force all existing code to be updated.

 3) After a while change
 MyClassName aElement;
 to implicit mean
 MyClassName aElement = new MyClassName;


 But even with =null I would be surprised if Walter goes
 for it. The proposal doesn't feel right to me for two reasons: 1) an
 expensive operation like "new" shouldn't be implicit,


 Not even if you need it anyway 99.99% of the time ?


 and 2) it would mean
 the code
 Foo a;
 a = ...;
 is different than
 Foo a = ...;
 Even though C++ distinguishes between initialization and assignment I 
 don't
 D should go down that road.
Mar 25 2005
prev sibling next sibling parent "Lionello Lunesu" <lio lunesu.removethis.com> writes:
Hey,

Just a short remark...

In my toolkit I use some 'smart pointer' classes (kind-of like CComPtr in 
ATL) and one of the nice things is a constructor that can new the object:

// c++ pseudo code from the top of my head
enum _newnow { NEWNOW=1; }
template <class T>
class SmartPtr
{
  T* ptr;
  SmartPtr() : ptr(NULL) {}
  SmartPtr(_newnow) { ptr = new T; }
// more stuff, a.o. dereference operator etc..
};

//Use it as follows:
SmartPtr<SomeClass> sca;        // will be NULL
SmartPtr<SomeClass> scb(NEWNOW);
sc->Bla();

This syntax seems doable? Could be like this:

// D now
class Whatever { ... };

Whatever wa;        // will be NULL;
Whatever wa();        // new, default constructor
Whatever wa(...);    // new, constructor with arguments

Won't break any code, since "Whatever wa();" is illegal? Would be very nice 
if "auto Whatever wa();" would behave as if the object was made on the stack 
in C++. Maybe the compiler can even choose to do it on the stack, when it 
gets smarter!

Lionello.
Mar 25 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 24 Mar 2005 19:01:10 -0500, Ben Hinkle wrote:


 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1hyzck675ctcf$.14kdoa1p26fdc$.dlg 40tude.net...

 On Thu, 24 Mar 2005 17:58:31 -0500, Ben Hinkle wrote:


 <12tkvvb02 sneakemail.com> wrote in message
 news:d1uve0$2ca$1 digitaldaemon.com...

 Hi

 This is the monthly status for the unofficial d wish list:
 http://all-technology.com/eigenpolls/dwishlist/

 Right now the wish list looks like this:

 0.565  5  Auto new-ing of classes


 I'd be very surprised if Walter changes the language to do that. The 
 current
 system is much better.


 I submitted this one. There is further discussion at ...

 http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/AutoNewingOfClasses


 
 The =null makes more sense than the =!new. How did it turn into !new on the 
 eigenpoll? oh well. 


It was the other way round, actually. I first put it into the poll with the
"=!new" and later it was pointed out to me that this was not clever. I
agree and when I wrote it up in the wiki I changed it to the "=null"
syntax.

I think my original idea has taken off into directions I didn't intend it
to go, but that's normal I guess. My original feeling was just to switch
the default behaviour such that the more common usage would be reflected in
simpler syntax.

We currently do ...
  struct Sct { . . .}
  class CLS {  . . .}
  int   a;
  int[] b;
  Sct   c;
  Cls   d = new Cls;

to make each of the variables usable, and I see that the requirement to use
'new' is an anomaly. So all I was suggesting was that seeing the form
"CLASS a = new CLASS;" is such a common idiom, that a simpler syntax would
be appreciated.

It has nothing to do with C++ or Java behaviour as I don't use those
languages, and really couldn't care less what they do or don't do. I'm
trying to make D more coder/reader friendly.

I first fell foul of this requirement when I had struct being used in me
application, and later I changed it to a class; then all of a suddenly I
had Access Violations all over the place :-(

I still forget to add the "= new <whatever>;" occasionally and trip up
during testing. 


But even with =null I would be surprised if Walter goes 
 for it.


Me too, but not for the reasons you speak of. I guess it means work for him
to change things and he is already too busy. ;-)


 The proposal doesn't feel right to me for two reasons: 1) an 
 expensive operation like "new" shouldn't be implicit,


real[50000] x;

Is also implicit (the is no 'new' involved) but every one knows what's
going on. 

The idiom 'CLASS x = new CLASS;' is very common. So why not make coding
easier to write and read. 


 and 2) it would mean 
 the code
 Foo a;
 a = ...;
 is different than
 Foo a = ...;
 
 Even though C++ distinguishes between initialization and assignment I don't 
 D should go down that road.


How is that different from ...

  char[] S;   // Initialize the array
  S =  . . .; // Assign the array.

If one knows the rule that 'Foo a;' invokes the default constructor, and
one doesn't want that, then code it as 'Foo a=null;'. I still suspect that
this is a minority of cases.

Even though I concede that we are never likely to see Walter change this, I
can still voice an opinion, no?

-- 
Derek Parnell
Melbourne, Australia
26/03/2005 4:48:08 PM
Mar 25 2005
next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 The =null makes more sense than the =!new. How did it turn into !new on 
 the
 eigenpoll? oh well.


 It was the other way round, actually. I first put it into the poll with 
 the
 "=!new" and later it was pointed out to me that this was not clever. I
 agree and when I wrote it up in the wiki I changed it to the "=null"
 syntax.


oh, ok.


 I think my original idea has taken off into directions I didn't intend it
 to go, but that's normal I guess. My original feeling was just to switch
 the default behaviour such that the more common usage would be reflected 
 in
 simpler syntax.

 We currently do ...
  struct Sct { . . .}
  class CLS {  . . .}
  int   a;
  int[] b;
  Sct   c;
  Cls   d = new Cls;

 to make each of the variables usable, and I see that the requirement to 
 use
 'new' is an anomaly. So all I was suggesting was that seeing the form
 "CLASS a = new CLASS;" is such a common idiom, that a simpler syntax would
 be appreciated.


The anomaly is that classes must be new'ed since they aways have reference 
semantics while the other types have value semantics so to get reference 
semantics you have to new them. So having the new for Cls makes it 
consistent with newing the other types.


 It has nothing to do with C++ or Java behaviour as I don't use those
 languages, and really couldn't care less what they do or don't do. I'm
 trying to make D more coder/reader friendly.


a good goal


 I first fell foul of this requirement when I had struct being used in me
 application, and later I changed it to a class; then all of a suddenly I
 had Access Violations all over the place :-(


That's a good thing that it crashed since reference semantics is vastly 
different than value semantics and implicitly newing them would have 
introduced bugs that would probably be harder to track down than a crash.


 I still forget to add the "= new <whatever>;" occasionally and trip up
 during testing.


ok


 The proposal doesn't feel right to me for two reasons: 1) an
 expensive operation like "new" shouldn't be implicit,


 real[50000] x;

 Is also implicit (the is no 'new' involved) but every one knows what's
 going on.


True but initialization it consistent across all types.


 The idiom 'CLASS x = new CLASS;' is very common. So why not make coding
 easier to write and read.


True it is common.


 and 2) it would mean
 the code
 Foo a;
 a = ...;
 is different than
 Foo a = ...;

 Even though C++ distinguishes between initialization and assignment I 
 don't
 D should go down that road.


 How is that different from ...

  char[] S;   // Initialize the array
  S =  . . .; // Assign the array.


I don't see the connection with dynamic arrays. Declaring a dynamic array 
does not allocate any memory for it.


 Even though I concede that we are never likely to see Walter change this, 
 I
 can still voice an opinion, no?


absolutely. I don't mean to sound harsh. I was just voicing my concerns 
about a proposal that I saw at the top of the eigenpoll. I'm now wondering 
just how this eigenpoll works since every post looks like a random bunch of 
data.
Mar 26 2005
prev sibling next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 26 Mar 2005 17:21:25 +1100, Derek Parnell <derek psych.ward> wrote:

 On Thu, 24 Mar 2005 19:01:10 -0500, Ben Hinkle wrote:


 "Derek Parnell" <derek psych.ward> wrote in message
 news:1hyzck675ctcf$.14kdoa1p26fdc$.dlg 40tude.net...

 On Thu, 24 Mar 2005 17:58:31 -0500, Ben Hinkle wrote:


 <12tkvvb02 sneakemail.com> wrote in message
 news:d1uve0$2ca$1 digitaldaemon.com...

 Hi

 This is the monthly status for the unofficial d wish list:
 http://all-technology.com/eigenpolls/dwishlist/

 Right now the wish list looks like this:

 0.565  5  Auto new-ing of classes


 I'd be very surprised if Walter changes the language to do that. The
 current
 system is much better.


 I submitted this one. There is further discussion at ...

 http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/AutoNewingOfClasses


 The =null makes more sense than the =!new. How did it turn into !new on  
 the
 eigenpoll? oh well.


 It was the other way round, actually. I first put it into the poll with  
 the
 "=!new" and later it was pointed out to me that this was not clever. I
 agree and when I wrote it up in the wiki I changed it to the "=null"
 syntax.

 I think my original idea has taken off into directions I didn't intend it
 to go, but that's normal I guess. My original feeling was just to switch
 the default behaviour such that the more common usage would be reflected  
 in
 simpler syntax.

 We currently do ...
   struct Sct { . . .}
   class CLS {  . . .}
   int   a;
   int[] b;
   Sct   c;
   Cls   d = new Cls;

 to make each of the variables usable, and I see that the requirement to  
 use 'new' is an anomaly.


I think perhaps if you look at it from a different view/perspective...

For example:

   Cls d;

Allocates a "reference" on the "stack".

   int[] b;

Allocates a "reference" on the "stack".

   Cls d = new Cls();

Allocates a "reference" on the "stack" then allocates a "Cls" on the  
"heap".

   int[] b = new int[100];

Allocates a "reference" on the "stack" then allocates a block of memory on  
the "heap".

'int' and structs are the same as references, they are allocated on the  
"stack".

So, "new" indicates "heap" allocation. Values assigned to references  
generally(always?) involve "heap" memory i.e. array contents, and classes.


 So all I was suggesting was that seeing the form
 "CLASS a = new CLASS;" is such a common idiom, that a simpler syntax  
 would
 be appreciated.


This I can agree with, at least a little, I think perhaps:

Cls d();
Cls e(1,2,3);

could be shorthand for:

Cls d = new Cls();
Cls e = new Cls(1,2,3);

but, it does make it harder to search for heap allocations (no 'new' to  
look for) and it does make it less obvious they are going on. So I can  
understand reservation about adding this sort of shorthand.


 It has nothing to do with C++ or Java behaviour as I don't use those
 languages, and really couldn't care less what they do or don't do. I'm
 trying to make D more coder/reader friendly.


An admirable goal.


 I first fell foul of this requirement when I had struct being used in me
 application, and later I changed it to a class; then all of a suddenly I
 had Access Violations all over the place :-(


Yeah.. I've been bitten by the difference between struct and class, tho my  
experience was WRT to in/out/inout variables. I think the difference is a  
good this, why have two shovels when I can have a shovel and a fork.  
Different tools for different tasks, remember how to use your tools.


 The proposal doesn't feel right to me for two reasons: 1) an
 expensive operation like "new" shouldn't be implicit,


 real[50000] x;

 Is also implicit (the is no 'new' involved) but every one knows what's
 going on.


This is a static array.. there is no requirement that the memory be  
allocated on the "heap" (IIRC and I may not) so it could be "stack"  
memory, and/or static ROM (in the case of a static array). If the memory  
is on the heap then you can say, "x" is a reference on the "stack"  
referencing "heap" memory of size "50000".


 and 2) it would mean
 the code
 Foo a;
 a = ...;
 is different than
 Foo a = ...;

 Even though C++ distinguishes between initialization and assignment I  
 don't
 D should go down that road.


 How is that different from ...

   char[] S;   // Initialize the array
   S =  . . .; // Assign the array.


It's not.

"char[] S;" - allocates a "reference" on the "stack".
"S = " - assigns something to that reference. (generally "heap" memory")


 If one knows the rule that 'Foo a;' invokes the default constructor, and
 one doesn't want that, then code it as 'Foo a=null;'. I still suspect  
 that
 this is a minority of cases.


I can't say whether wanting "null" or wanting "not null" is more common, I  
suspect it's a matter of style.


 Even though I concede that we are never likely to see Walter change  
 this, I
 can still voice an opinion, no?


Yep. Keep em coming.

Regan
Mar 26 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 It has nothing to do with C++ or Java behaviour as I don't use those
 languages, and really couldn't care less what they do or don't do. I'm
 trying to make D more coder/reader friendly.


Java has the same behaviour as D, in that Object variables are just
references and different from primitive types (they are also similar)

People have been tripping up on "NullPointerException" (i.e. the Java
equivalent of the Access Violation error that D has) for a long time...


There are extensions to Java that eliminates both NullPointerException
and ClassCastException, such as the "Nice" programming language...

(note that the ClassCastException in D becomes a "NullPointerException"
instead, since a cast() that can't be done simply returns null instead)

http://nice.sourceforge.net/safety.html:

 In current imperative languages, references (or pointers) can hold a
 special value meaning "reference to nothing". This value is called null
 in Java, NULL in C and C++. At run time, however, dereferencing this
 value results to a runtime error (NullPointerException) or a run time
 crash (bus error, segmentation fault, protection fault, ...).


I'm not sure I like their "solution" to it, but they do offer one...
(it's detailed on the page that is reference by the hyperlink above)

Another one is at: http://c2.com/cgi/wiki?NullConsideredHarmful
(there's a lot of good stuff at that page, and the ones it links to)


So what C++ and Java does *can* be relevant to the discussion, not just
for compatibility, but to see how they address the very same problem ?

In the Java case, it doesn't have either pointers nor structures, which
makes it easier to avoid mixing value types and reference types up...

The plot in D thickens, if you e.g. compare the difference between null 
objects and null arrays, for instance if you try to print one Object and 
one char[] which both have a value of "null". Very different results...
(similar to trying to use '==' to compare objects vs. comparing strings)

--anders
Mar 26 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 27 Mar 2005 00:29:39 +0100, Anders F Björklund wrote:


 Derek Parnell wrote:
 

 It has nothing to do with C++ or Java behaviour as I don't use those
 languages, and really couldn't care less what they do or don't do. I'm
 trying to make D more coder/reader friendly.


 
 Java has the same behaviour as D, in that Object variables are just
 references and different from primitive types (they are also similar)


[snip]


 So what C++ and Java does *can* be relevant to the discussion, not just
 for compatibility, but to see how they address the very same problem ?


[snip]

To me, it doesn't matter what <YourFavouriteProgrammingLangauge> does, and
yes it is interesting to see how other languages deal with that problem.
But the problem I'm having is explain what I see that problem is ;-)

Here's another stab at it ...

A common idiom (invoking the default constructor) has significantly more
keystrokes than the less common idiom (initializing the class reference to
null). Why can we change that situation, such that the common idiom uses
less keystrokes but still remains readable?

The issue I'm highlighting is not about reference types vs heap types, C++
vs Java, initialization vs assignment, etc... It has to do with making
program source code easier to write and easier to read. I am not
dogmatically saying *my* suggestion *must* be implemented. My suggestion is
just a starting point for other, probably better, ideas.

Anyhow, I give up. You guys have beaten me into silence on this issue.

-- 
Derek Parnell
Melbourne, Australia
27/03/2005 10:20:10 AM
Mar 26 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 Anyhow, I give up. You guys have beaten me into silence on this issue.


geez, now you're making me feel bad for saying anything negative about your 
proposal. :P oh well. I'm sorry you feel that way. I feel like we all have 
understood each other's point of view and disagree on the conclusions - 
which happens all the time in situations where the conclusions are 
subjective. I'm probalby reading too much into that closing, but I hope you 
don't feel beaten up.
Mar 26 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 26 Mar 2005 20:05:58 -0500, Ben Hinkle <ben.hinkle gmail.com>  
wrote:


 Anyhow, I give up. You guys have beaten me into silence on this issue.


 geez, now you're making me feel bad for saying anything negative about  
 your
 proposal. :P oh well. I'm sorry you feel that way. I feel like we all  
 have
 understood each other's point of view and disagree on the conclusions -
 which happens all the time in situations where the conclusions are
 subjective. I'm probalby reading too much into that closing, but I hope  
 you
 don't feel beaten up.


with(ben) /me

:)

Regan
Mar 27 2005
prev sibling next sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Sun, 27 Mar 2005 10:30:52 +1000, Derek Parnell wrote:


 
 Anyhow, I give up. You guys have beaten me into silence on this issue.


That why I made the wish list. When someone make a suggestion only 
people how disagree reply on it. 
But your suggestion is still doing well on the wish list,
and the similar "short syntax for new" is coming along fine.

Knud
Mar 26 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Knud Sørensen wrote:

 On Sun, 27 Mar 2005 10:30:52 +1000, Derek Parnell wrote:
 
 

Anyhow, I give up. You guys have beaten me into silence on this issue.


 
 
 That why I made the wish list. When someone make a suggestion only 
 people how disagree reply on it. 
 But your suggestion is still doing well on the wish list,
 and the similar "short syntax for new" is coming along fine.


Early C chose to "abbreviate" some common things, to "save ink". They've 
regretted some of them ever since. (Sorry for not giving exact reference 
here.)
Mar 29 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 A common idiom (invoking the default constructor) has significantly more
 keystrokes than the less common idiom (initializing the class reference to
 null). Why can we change that situation, such that the common idiom uses
 less keystrokes but still remains readable?


The problem you highlight is a very real one, and has come up for people
that begin programming in (again, just "for instance") Java a long time.

D has improved the situation regarding arrays, so that those don't crash
when trying to get the length of a null array (a good help for strings)

But it still does for uninitialized objects, like when you try to writef
one or even when you just try to check if it's equal ('==') and so on...

Improving that is a worthy goal.


 The issue I'm highlighting is not about reference types vs heap types, C++
 vs Java, initialization vs assignment, etc... It has to do with making
 program source code easier to write and easier to read. I am not
 dogmatically saying *my* suggestion *must* be implemented. My suggestion is
 just a starting point for other, probably better, ideas.
 
 Anyhow, I give up. You guys have beaten me into silence on this issue.


That's not good, I just didn't think your solution was the 1 cure...
(as in: I would just find it confusing, being used to the "old way")

Not that there isn't a real problem of the code throwing NullError
(or worse, like causing segfaults left and right) Because there is!


We can take it to the wiki (FeatureRequestList/AutoNewingOfClasses),
but at first a glance it seems to be more about missing the (C++)
stack class declaration syntax, only to sometimes still return null ?
(like if the class is question didn't have any zero-arg constructor)

And there are more interesting ways to "solve" this than by syntactical
sugar, for instance by changing null into nil or by having full objects.
(nil is a "bottom type", pretty much the same as a Java "NullObject" -
and a "full" or "mandatory" object is one that simply can't be null...)

http://c2.com/cgi/wiki?WhatIsNull

 What is NULL? Baby, don't hurt me... -- Dr. Haddaway


http://c2.com/cgi/wiki?NullObject
http://c2.com/cgi/wiki?NullConsideredHarmful

All of these would break a lot of existing code, but are IMHO still
interesting topics for a discussion. (Sorry that you disagree there.)

I feel it's very much related to both .init values and hash tables, too.
Whether it is for D 1.0, 2.0 or D 3 Standard Edition version 7, I dunno?

--anders
Mar 27 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 27 Mar 2005 10:43:26 +0200, Anders F Björklund <afb algonet.se>  
wrote:

 Derek Parnell wrote:


 A common idiom (invoking the default constructor) has significantly more
 keystrokes than the less common idiom (initializing the class reference  
 to
 null). Why can we change that situation, such that the common idiom uses
 less keystrokes but still remains readable?


 The problem you highlight is a very real one, and has come up for people
 that begin programming in (again, just "for instance") Java a long time.

 D has improved the situation regarding arrays, so that those don't crash
 when trying to get the length of a null array (a good help for strings)


This is because an array is a "reference", "length" is a property of that  
"reference", and the "reference" itself is not null, just the data it  
refers to. In other words the reference itself is a value type.

A class reference is only different in that it doesn't have a property  
other than the data it refers to i.e. it has no "length" property. If it  
had a property like "length" you could probably use that property even  
if/when the data it referred to was null.

I suspect you (Anders) already realise all this, but, I felt the need to  
share.

Regan
Mar 27 2005
prev sibling next sibling parent reply David Medlock <nospam nospam.com> writes:
Ben Hinkle wrote:

 <12tkvvb02 sneakemail.com> wrote in message 
 news:d1uve0$2ca$1 digitaldaemon.com...
 

Hi

This is the monthly status for the unofficial d wish list:
http://all-technology.com/eigenpolls/dwishlist/

Right now the wish list looks like this:

0.565  5  Auto new-ing of classes


 
 
 wow - I'm surprised this is popular (though I don't know how many people 
 have voted or how often). For those who didn't follow the link, here's the 
 description of auto new'ing:
 Foo A;
 is shorthand for Foo A = new Foo and
 Foo A = !new
 would be the way of initializing to null.
 
 I'd be very surprised if Walter changes the language to do that. The current 
 system is much better. 
 
 


Syntaxes are like opinions, everyone has them, they usually only like 
their own.

How about:
auto Foo A;

Cleaner and doesnt break much(if any) code.
-David
Mar 24 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 24 Mar 2005 19:48:06 -0500, David Medlock <nospam nospam.com>  
wrote:

 Ben Hinkle wrote:

 <12tkvvb02 sneakemail.com> wrote in message  
 news:d1uve0$2ca$1 digitaldaemon.com...


 Hi

 This is the monthly status for the unofficial d wish list:
 http://all-technology.com/eigenpolls/dwishlist/

 Right now the wish list looks like this:

 0.565  5  Auto new-ing of classes


   wow - I'm surprised this is popular (though I don't know how many  
 people have voted or how often). For those who didn't follow the link,  
 here's the description of auto new'ing:
 Foo A;
 is shorthand for Foo A = new Foo and
 Foo A = !new
 would be the way of initializing to null.
  I'd be very surprised if Walter changes the language to do that. The  
 current system is much better.


 Syntaxes are like opinions, everyone has them, they usually only like  
 their own.

 How about:
 auto Foo A;

 Cleaner and doesnt break much(if any) code.
 -David


"auto" already has a meaning.
http://www.digitalmars.com/d/attribute.html#auto

Regan
Mar 25 2005
prev sibling parent renox <renosky free.fr> writes:
Ben Hinkle wrote:

0.565  5  Auto new-ing of classes


 
 wow - I'm surprised this is popular (though I don't know how many people 
 have voted or how often). For those who didn't follow the link, here's the 
 description of auto new'ing:
 Foo A;
 is shorthand for Foo A = new Foo and
 Foo A = !new
 would be the way of initializing to null.
 
 I'd be very surprised if Walter changes the language to do that. The current 
 system is much better. 


I agree, it's ugly especially since there is now type inference, instead 
of writing Foo A = new Foo; I think that you can just write
auto A = new Foo;
No need to repeat Foo so I see no need of this feature.

Or am I mistaken?

Regards,
RenoX
Jun 02 2006