Null references (oh no, not again!)
Walter Bright
newshound1 at digitalmars.com
Wed Mar 4 21:20:40 PST 2009
Andrei Alexandrescu wrote:
> Reality seems to disagree. The rule is well understood in Java and C#
> and I haven't heard of gotchas involving it. Here are the first two hits
> on searching java gotchas:
>
> http://mindprod.com/jgloss/gotchas.html
> http://www.firstsql.com/java/gotchas/
>
> The first actually discusses construction issues, but the flow thing is
> not among them.
Java and C# don't have templates or mixins generating code, either.
Disallowing certain combinations makes it hard to compose things using
metaprogramming.
> The code is bug-ridden. It's exactly the kind of maintenance nightmare
> where you change one line and 1000 lines below something crashes.
It does occur in various forms. I know this from experimenting with flow
analysis. The problem with saying it's "buggy" is then the programmer
throws in a dead assignment to "fix" it rather than refactor it.
> Listen to the man. The point is to use non-null as default in function
> signatures, but relax that rule non-locally so programmers don't feel
> constrained. It's the best of all worlds.
But much of this thread is about tracking where a null assignment to a
field is coming from. By doing only local analysis, that case is not
dealt with at all.
>> I'll bet that they added this constraint when they got a bug report
>> about that hole <g>.
> Link? Evidence?
No evidence. Just that's how these things usually work <g>.
> No. This is exactly the point at which the useless "out" storage class
> can make itself useful. You can pass an uninitialized variable as an
> "out" (not ref) parameter, and the callee has the modularly checked
> obligation to assign to it. It's perfect.
I'll concede that one.
> You have no case.
Not so fast :-)
More information about the Digitalmars-d
mailing list