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

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

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

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.)

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