June 19, 2005
On Sat, 18 Jun 2005 12:39:54 +0000 (UTC), Nick <Nick_member@pathlink.com> wrote:
> Regan Heath:
>> I can't see a downside to ensuring the distinction remains
>
> The downside IMHO is that it makes strings and arrays more complicated objects,
> having not two states (non-empty and empty) but three (non-empty, empty and
> null). This makes them more confusing, and I think the coding style that this
> encourages will be less readable and more prone to have hard-to-find bugs. But
> that's just my opinion.

Cool. Got any examples or evidence to support this opinion? I ask because, like I said, if you can write:

char[] a = null;
if (a.length == 0)

without getting a seg-v (due to a being null), then you can effectively treat arrays as having 2 states, not 3. So, unless you care about state #3 you can ignore it and never have any trouble, confusion or hard-to-find bugs.

Regan
June 19, 2005
In article <opsslpgewu23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>Cool. Got any examples or evidence to support this opinion?

Well, not any specific examples as such. But the problem is that when you add 'null' as a distinct state, what should happen with equality? If I do a="" and b=null, then you probably agree that a==b should still be true. But that means the two states are not really distinct after all, if you think of equality == as a proper way of defining distinct states. So arrays become "2.5"-state objects, and that might be a bit confusing.

One of the consequences is that the order in which you compare things becomes important, eg.

if(a == null) do something
else if(a == b) do something else
else do something entirely different

is NOT the same as

if(a == b) do something else
else if(a == null) do something
else do something entirely different

since b might be "", and the first test would succeed even if a is null. Do the same with classes then your program will just crash, but the above will run and appear to work correctly even though it does not.

This probably isn't the end of the world, but it gives me an uneasy feeling.

>I ask because, like I said, if you can write:
>
>char[] a = null;
>if (a.length == 0)
>
>without getting a seg-v (due to a being null), then you can effectively treat arrays as having 2 states, not 3. So, unless you care about state #3 you can ignore it and never have any trouble, confusion or hard-to-find bugs.

Well, ok, but it really isn't a matter of whether or not _I_ am using 2 or 3 states. If the feature is there (and documented), then people will use it.

I believe in the current D mantra of making bugs harder to write and easier to find. Having a semi-destinct 'null'-state in arrays doesn't go along with that goal, IMHO.

Nick


June 19, 2005
On Sun, 19 Jun 2005 22:02:06 +0000 (UTC), Nick wrote:

> In article <opsslpgewu23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>Cool. Got any examples or evidence to support this opinion?
> 
> Well, not any specific examples as such. But the problem is that when you add 'null' as a distinct state, what should happen with equality? If I do a="" and b=null, then you probably agree that a==b should still be true.

No I would not. They are two different things. Just like ...

  if ("" == null)

doesn't make sense.

> But that means
> the two states are not really distinct after all, if you think of equality == as
> a proper way of defining distinct states. So arrays become "2.5"-state objects,
> and that might be a bit confusing.

Except that I disagree with you about empty and null being equal.

> One of the consequences is that the order in which you compare things becomes important, eg.
> 
> if(a == null) do something
> else if(a == b) do something else
> else do something entirely different
> 
> is NOT the same as
> 
> if(a == b) do something else
> else if(a == null) do something
> else do something entirely different

Correct. We already do such tests with class instances, for example.

> since b might be "", and the first test would succeed even if a is null.
But it shouldn't.

> Do the
> same with classes then your program will just crash, but the above will run and
> appear to work correctly even though it does not.
> 
> This probably isn't the end of the world, but it gives me an uneasy feeling.
> 
>>I ask because, like I said, if you can write:
>>
>>char[] a = null;
>>if (a.length == 0)
>>
>>without getting a seg-v (due to a being null), then you can effectively treat arrays as having 2 states, not 3. So, unless you care about state #3 you can ignore it and never have any trouble, confusion or hard-to-find bugs.
> 
> Well, ok, but it really isn't a matter of whether or not _I_ am using 2 or 3 states. If the feature is there (and documented), then people will use it.

Exactly. If empty and null were documented as two different states then people would know that and code accordingly.

> I believe in the current D mantra of making bugs harder to write and easier to find. Having a semi-destinct 'null'-state in arrays doesn't go along with that goal, IMHO.

Absolutely correct; having such a semi-state does not help anyone. However, that is *not* what we are talking about. We are talking about truly distinct states.

-- 
Derek Parnell
Melbourne, Australia
20/06/2005 8:54:21 AM
June 20, 2005
On Sun, 19 Jun 2005 22:02:06 +0000 (UTC), Nick <Nick_member@pathlink.com> wrote:
> In article <opsslpgewu23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>> Cool. Got any examples or evidence to support this opinion?
>
> Well, not any specific examples as such. But the problem is that when you add 'null' as a distinct state, what should happen with equality?

Nothing needs to change.

Equality is a comparrison of the value to which the reference refers, not a comparrison of the reference itself.
eg.

char[] p = null;

if (p is null) //compares the *referece* to null
if (p == null) //compares the *value* to which p refers with null
if (p == "") //compares the *value* to which p refers with ""

cases #2 and #3 can both be true, as they currently are, provided I can still compare the reference itself with null I have the 3 states required. In short:

reference is null //does not exit
value is null, value is "" //exists, is empty
value is "bob" //exists, is "bob"

> If I do a="" and b=null, then you probably agree that a==b should still be true.

I can, another option is to make null and "" distinct states for the *value* as well. I don't think we need to go that far, in fact I think it's better we don't.

<snip>

>> I ask because, like I said, if you can write:
>>
>> char[] a = null;
>> if (a.length == 0)
>>
>> without getting a seg-v (due to a being null), then you can effectively
>> treat arrays as having 2 states, not 3. So, unless you care about state #3
>> you can ignore it and never have any trouble, confusion or hard-to-find
>> bugs.
>
> Well, ok, but it really isn't a matter of whether or not _I_ am using 2 or 3 states. If the feature is there (and documented), then people will use it.
>
> I believe in the current D mantra of making bugs harder to write and easier to find. Having a semi-destinct 'null'-state in arrays doesn't go along with that goal, IMHO.

You're correct, which is why I'm not advocating that at all ;)

Regan
1 2 3 4
Next ›   Last »