View mode: basic / threaded / horizontal-split · Log in · Help
October 03, 2012
Re: References in D
On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała 
wrote:
> On Saturday, 15 September 2012 at 17:12:23 UTC, Jonathan M 
> Davis wrote:
>> On Saturday, September 15, 2012 15:24:27 Henning Pohl wrote:
>>> On Saturday, 15 September 2012 at 12:49:23 UTC, Russel Winder
>>> 
>>> wrote:
>>> > On Sat, 2012-09-15 at 14:44 +0200, Alex Rønne Petersen 
>>> > wrote:
>>> > […]
>>> > 
>>> >> Anyway, it's too late to change it now.
>>> > 
>>> > I disagree. There are always opportunities to make changes 
>>> > to
>>> > things,
>>> > you just have manage things carefully.
>>> 
>>> I don't know if people really use the ability of references 
>>> being
>>> null. If so, large amounts of code will be broken.
>>
>> Of course people use it. Having nullable types is _highly_ 
>> useful. It would
>> suck if references were non-nullable. That would be _horrible_ 
>> IMHO. Having a
>> means to have non-nullable references for cases where that 
>> makes sense isn't
>> necessarily a bad thing, but null is a very useful construct, 
>> and I'd _hate_
>> to see normal class references be non-nullable.
>>
>> - Jonathan M Davis
>
> Agreed. Nullable types are a feature not a bug. There is no 
> need to change it. Bugs occur when you do not know the language 
> rules and make assumptions instead. This can happen whith any 
> language and any rules. As to an example use of nullable 
> references: consider a board game (for example chess). The 
> boards has cells which can be empty or occupied. Model this 
> with an array of class objects  representing pieces. null 
> reference means a cell is not occupied. If you want to remove a 
> piece from the board assign null to it and GC will take care of 
> the rest. Now, doing this with full objects representing empty 
> cells would require needless work to define such "null" objects 
> and would be wasteful of memory (typically boards are sparsely 
> populated). Now imagine a really big board and every cell 
> holding references to useless objects simulating null 
> references. It would not make sense. Saying that null 
> references are evil is just propaganda. Let's keep D a sane 
> language.

Regarding my example: we could probably do with a single "null" 
object stored in all empty cells, but still this would be an 
unnecessary complication.
October 03, 2012
Re: References in D
On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek Czekała 
wrote:
> Agreed. Nullable types are a feature not a bug. There is no 
> need to change it. Bugs occur when you do not know the language 
> rules and make assumptions instead. This can happen whith any 
> language and any rules. As to an example use of nullable 
> references: consider a board game (for example chess). The 
> boards has cells which can be empty or occupied. Model this 
> with an array of class objects  representing pieces. null 
> reference means a cell is not occupied. If you want to remove a 
> piece from the board assign null to it and GC will take care of 
> the rest. Now, doing this with full objects representing empty 
> cells would require needless work to define such "null" objects 
> and would be wasteful of memory (typically boards are sparsely 
> populated). Now imagine a really big board and every cell 
> holding references to useless objects simulating null 
> references. It would not make sense. Saying that null 
> references are evil is just propaganda. Let's keep D a sane 
> language.

There is a related question at stackoverflow: 
http://stackoverflow.com/questions/693325/non-nullable-reference-types

As you can see the "nullable references are great" guy has been 
voted down.

I've written like 5k lines of code in D and never felt the need 
of using null. C++'s std::shared_ptr has the same issue, but at 
least it is called pointer.
October 03, 2012
Re: References in D
On Wednesday, 3 October 2012 at 10:41:34 UTC, Henning Pohl wrote:
> On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek 
> Czekała wrote:
>> Agreed. Nullable types are a feature not a bug. There is no 
>> need to change it. Bugs occur when you do not know the 
>> language rules and make assumptions instead. This can happen 
>> whith any language and any rules. As to an example use of 
>> nullable references: consider a board game (for example 
>> chess). The boards has cells which can be empty or occupied. 
>> Model this with an array of class objects  representing 
>> pieces. null reference means a cell is not occupied. If you 
>> want to remove a piece from the board assign null to it and GC 
>> will take care of the rest. Now, doing this with full objects 
>> representing empty cells would require needless work to define 
>> such "null" objects and would be wasteful of memory (typically 
>> boards are sparsely populated). Now imagine a really big board 
>> and every cell holding references to useless objects 
>> simulating null references. It would not make sense. Saying 
>> that null references are evil is just propaganda. Let's keep D 
>> a sane language.
>
> There is a related question at stackoverflow: 
> http://stackoverflow.com/questions/693325/non-nullable-reference-types
>
> As you can see the "nullable references are great" guy has been 
> voted down.
>
> I've written like 5k lines of code in D and never felt the need 
> of using null. C++'s std::shared_ptr has the same issue, but at 
> least it is called pointer.

Since when stackoverflow comment reputation is a word in a 
programming languages? Especially, in issue which is subject for 
human desire to escape from awareness and then complaining about 
arised problems.
October 03, 2012
Re: References in D
On Wednesday, 3 October 2012 at 10:41:34 UTC, Henning Pohl wrote:
> On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek 
> Czekała wrote:
>> Agreed. Nullable types are a feature not a bug. There is no 
>> need to change it. Bugs occur when you do not know the 
>> language rules and make assumptions instead. This can happen 
>> whith any language and any rules. As to an example use of 
>> nullable references: consider a board game (for example 
>> chess). The boards has cells which can be empty or occupied. 
>> Model this with an array of class objects  representing 
>> pieces. null reference means a cell is not occupied. If you 
>> want to remove a piece from the board assign null to it and GC 
>> will take care of the rest. Now, doing this with full objects 
>> representing empty cells would require needless work to define 
>> such "null" objects and would be wasteful of memory (typically 
>> boards are sparsely populated). Now imagine a really big board 
>> and every cell holding references to useless objects 
>> simulating null references. It would not make sense. Saying 
>> that null references are evil is just propaganda. Let's keep D 
>> a sane language.
>
> There is a related question at stackoverflow: 
> http://stackoverflow.com/questions/693325/non-nullable-reference-types
>
> As you can see the "nullable references are great" guy has been 
> voted down.
>
> I've written like 5k lines of code in D and never felt the need 
> of using null. C++'s std::shared_ptr has the same issue, but at 
> least it is called pointer.

The need of using null: Every type needs a default value. null 
supplies it perfectly for all class types in D. And it makes 
sense regardless of what stackoverflow self-appointed political 
commisars want you to believe. Consider my board example: with 
null standing for "empty cell" when a new board is created as an 
array it is by default empty -> in a meaningful state (think of 
games like Go, etc). And at any rate you are going to use a 
property/function like IsEmpty to check for empty cells. Why 
should it be a problem to implement it by comparing with null? If 
anything, it has a chance of being faster than when some other 
concrete reference is used. Without null references you will end 
up defining "null" objects all over the place (and sometimes it 
may just be impossible when all values are meaningful). Then you 
will have to store them globally and compare everything with 
these objects (named like NullBoard, NullPiece, NullPawn, etc, 
etc because it is ah so much better than just using a single 
keyword null) and if you forget your program will silently churn 
out garbage. With plain null references at least you would get an 
exception. I'd rather see an exception than have a program 
running smoothly with nonsensical results. Like seeing pieces 
vanishing because they are being captured with a "null" piece 
which I forgot to test for being "null". Because, you know, you 
will still have to test conditions in your program to make it 
meaningful, except that it may be a lot more troublesome when 
your program grows x2 in size because of all those "safety" 
mechanisms.
October 03, 2012
Re: References in D
On 2012-56-03 14:10,  wrote:

> The need of using null: Every type needs a default value.

Good gods, are we not done with this strawman yet?

No, not all types need a default value. In fact, for some types, it is
much better that they don't.


> Consider my board example: with null standing for "empty cell" when a  
> new board is created as an array it is by default empty -> in a  
> meaningful state (think of games like Go, etc).

Yes, null is useful. Nobody is trying to take null away from you.

What we want is the ability to say 'this can never be null', so that we
don't need to check for null over and over.


> And at any rate you are going to use a property/function like IsEmpty to  
> check for empty cells. Why should it be a problem to implement it by  
> comparing with null?

This is not what non-nullable references are about.

When not to use non-nullable references:
 - When the absence of a value is a valid value.
Example:
 - Chess board boxes.

When to use non-nullable references:
 - When the absence of a value is not a valid value.
Example:
 - RenderFoo(NotNull!Foo)


> Without null references you will end up defining "null" objects all over  
> the place (and sometimes it may just be impossible when all values are  
> meaningful).

No. Please read more about non-nullable references.


> Then you will have to store them globally and compare everything with  
> these objects (named like NullBoard, NullPiece, NullPawn, etc, etc  
> because it is ah so much better than just using a single keyword null)  
> and if you forget your program will silently churn out garbage. With  
> plain null references at least you would get an exception. I'd rather  
> see an exception than have a program running smoothly with nonsensical  
> results. Like seeing pieces vanishing because they are being captured  
> with a "null" piece which I forgot to test for being "null". Because,  
> you know, you will still have to test conditions in your program to make  
> it meaningful, except that it may be a lot more troublesome when your  
> program grows x2 in size because of all those "safety" mechanisms.

This... Please... Please, just read more about the topic before
commenting. Please.

-- 
Simen
October 03, 2012
Re: References in D
On Wednesday, 3 October 2012 at 14:49:36 UTC, Simen Kjaeraas 
wrote:
> On 2012-56-03 14:10,  wrote:
>
>> The need of using null: Every type needs a default value.
>
> Good gods, are we not done with this strawman yet?
>
> No, not all types need a default value. In fact, for some 
> types, it is
> much better that they don't.
>
>
>> Consider my board example: with null standing for "empty cell" 
>> when a new board is created as an array it is by default empty 
>> -> in a meaningful state (think of games like Go, etc).
>
> Yes, null is useful. Nobody is trying to take null away from 
> you.
>
> What we want is the ability to say 'this can never be null', so 
> that we
> don't need to check for null over and over.
>
>
>> And at any rate you are going to use a property/function like 
>> IsEmpty to check for empty cells. Why should it be a problem 
>> to implement it by comparing with null?
>
> This is not what non-nullable references are about.
>
> When not to use non-nullable references:
>  - When the absence of a value is a valid value.
> Example:
>  - Chess board boxes.
>
> When to use non-nullable references:
>  - When the absence of a value is not a valid value.
> Example:
>  - RenderFoo(NotNull!Foo)
>
>
>> Without null references you will end up defining "null" 
>> objects all over the place (and sometimes it may just be 
>> impossible when all values are meaningful).
>
> No. Please read more about non-nullable references.
>
>
>> Then you will have to store them globally and compare 
>> everything with these objects (named like NullBoard, 
>> NullPiece, NullPawn, etc, etc because it is ah so much better 
>> than just using a single keyword null) and if you forget your 
>> program will silently churn out garbage. With plain null 
>> references at least you would get an exception. I'd rather see 
>> an exception than have a program running smoothly with 
>> nonsensical results. Like seeing pieces vanishing because they 
>> are being captured with a "null" piece which I forgot to test 
>> for being "null". Because, you know, you will still have to 
>> test conditions in your program to make it meaningful, except 
>> that it may be a lot more troublesome when your program grows 
>> x2 in size because of all those "safety" mechanisms.
>
> This... Please... Please, just read more about the topic before
> commenting. Please.

> When to use non-nullable references:
>  - When the absence of a value is not a valid value.

As my comments indicated : the presence of a value does not 
guarantee a valid value by itself. The C++ declaration int n; 
introduces a value, good luck using it. In short, having null 
references is useful (a value outside of the type cannot be 
introduced easily unless the language gives a hand, check eof() 
in C++ character_traits), while forcing non-null references 
hardly offers any significant advantage. Not enough to justify 
complicating the syntax of the language to have it both ways.
October 03, 2012
Re: References in D
On Wednesday, 3 October 2012 at 12:56:41 UTC, Franciszek Czekała 
wrote:
> The need of using null: Every type needs a default value.

This is just plain wrong. There even is a feature in D which 
solely exists for the purpose of allowing struct types _not_ to 
have a default value (@disable this)…

David
October 03, 2012
Re: References in D
On 2012-10-03, 18:12,  wrote:

> As my comments indicated : the presence of a value does not guarantee a  
> valid value by itself. The C++ declaration int n; introduces a value,  
> good luck using it.

Which is why non-nullable references must not allow the programmer to
declare them without also assigning a valid value (hence the no default
value [note that this is completely different from 'random default value',
which is what you indicate above]). This is easily checkable in a
constructor.


> In short, having null references is useful (a value outside of the type  
> cannot be introduced easily unless the language gives a hand, check  
> eof() in C++ character_traits),

Good gripes, I thought we'd been through this. If you need null, use
it, already! Nobody is trying to take it away, we're suggesting that
most uses of pointers/references should never be null, and such a
constraint can and should be modeled in the type system.

It's also worth pointing out that others have invented (non-null)
sentinel values even for nullable types.


> while forcing non-null references hardly offers any significant
> advantage.

They make sure you never pass null to a function that doesn't expect
null - I'd say that's a nice advantage.

As you may well be aware, reals are supersets of longs, just like
nullable references are supersets of non-nullable references. If
the argument was that (performance aside) you should simply use
real wherever a long was needed, would you consider that a good idea?
I mean, it's just a matter of making sure you never store a NaN or
other non-integer in it.

The example is admittedly more extreme, but the general idea is the
same.

-- 
Simen
October 03, 2012
Re: References in D
On Wednesday, 3 October 2012 at 16:11:53 UTC, Franciszek Czekała 
wrote:
> As my comments indicated : the presence of a value does not
> guarantee a valid value by itself. The C++ declaration int n; 
> introduces a value, good luck using it.
auto c = new Class();

Tell me, does c contain an invalid value now?

> In short, having null references is useful (a value outside of 
> the type cannot be introduced easily unless the language gives 
> a hand, check eof() in C++ character_traits),
Null references are useful, that's right. Nobody wants to take 
them away. Just put something like a questionmark behind the 
reference type to indicate that it's nullable.

> while forcing non-null references hardly offers any significant 
> advantage.
1) Performance, no or very few null-checks.
2) Code is shorter, looks better, less duplications.
3) Clarity. User of functions know, whether a function can return 
null at compile time.

> Not enough to justify complicating the syntax of the language 
> to have it both ways.
Not really. It's all about one question mark for example.
October 03, 2012
Re: References in D
On Wednesday, 3 October 2012 at 16:36:15 UTC, Henning Pohl wrote:
> Just put something like a questionmark behind the reference 
> type to indicate that it's nullable.
...
> Not really. It's all about one question mark for example.

How much code would be broken by moving nullable references from 
current state to "question mark notation"?

I expect that non-nullable class objects (called references here) 
addition (if there is no objections to idea in general) would not 
break much code and would not request vast syntax changes. And it 
likely can be done by still defaulting to nullable references. 
For example, it can be done with the help of @nonnullable (like 
immutable) type qualifier and semantic check of operations 
involving references with such qualifier. Anyway, my estimation 
of probability of accepting constructions like "type&", "type*?", 
etc and defaulting to non-null references is very low, at least 
for D2.
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home