March 30, 2005
"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsoe3wkh323k2f5@nrage.netwin.co.nz...
> On Tue, 29 Mar 2005 08:29:36 -0500, Ben Hinkle <ben.hinkle@gmail.com> wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsoeax3jt23k2f5@nrage.netwin.co.nz...
>>> On Mon, 28 Mar 2005 21:13:54 -0500, Ben Hinkle <ben.hinkle@gmail.com> wrote:
>>>> I take it you define empty to be non-null ptr and 0 length, correct?
>>>
>>> "empty" - "Holding or containing nothing."
>>>
>>> In my mind something is "empty" if it:
>>>   a. contains nothing.
>>>   b. exists.
>>>
>>> It cannot be "empty" if it contains something.
>>> It cannot be "empty" if it does not exist.
>>>
>>> So, my first question. How do I represent "non existant" in D?
>>
>> What you describe is ok with me but I don't think it maps well to D's arrays.
>
> Exactly my point. It would only take a few small changes to "fix" the problem as I see it.

Java arrays have the semantics you describe. They distinguish between null/empty/non-empty and none compare as equal to the others. In fact even trying to compare a null array throws an exception much like trying to call opEquals on a null object reference throws an exception. It's a very reasonable thing to do. The main trouble with Java array semantics is that APIs wind up choosing between null and empty fairly randomly and so many Java array bugs are introduced by guessing some function returns "empty" when it in fact returns null. It's easier to focus instead on only distinguishing empty/non-empty, which is what D does. One can think up APIs where having a third, null, choice would be useful but almost all the time the practical uses of an array are covered by empty/non-empty.

>> The foreach will stop automatically at eof. It's like a foreach stopping at the end of an array when it has no more elements. It doesn't run once more with null - it just stops.
>
> Which foreach? My one? Assume now that I remove the eof() check. What happens now?

It would iterate forever just like any loop that doesn't have an ending condition.


March 30, 2005
On Tue, 29 Mar 2005 19:17:55 -0500, Ben Hinkle <ben.hinkle@gmail.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsoe3wkh323k2f5@nrage.netwin.co.nz...
>> On Tue, 29 Mar 2005 08:29:36 -0500, Ben Hinkle <ben.hinkle@gmail.com>
>> wrote:
>>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>>> news:opsoeax3jt23k2f5@nrage.netwin.co.nz...
>>>> On Mon, 28 Mar 2005 21:13:54 -0500, Ben Hinkle <ben.hinkle@gmail.com>
>>>> wrote:
>>>>> I take it you define empty to be non-null ptr and 0 length, correct?
>>>>
>>>> "empty" - "Holding or containing nothing."
>>>>
>>>> In my mind something is "empty" if it:
>>>>   a. contains nothing.
>>>>   b. exists.
>>>>
>>>> It cannot be "empty" if it contains something.
>>>> It cannot be "empty" if it does not exist.
>>>>
>>>> So, my first question. How do I represent "non existant" in D?
>>>
>>> What you describe is ok with me but I don't think it maps well to D's
>>> arrays.
>>
>> Exactly my point. It would only take a few small changes to "fix" the
>> problem as I see it.
>
> Java arrays have the semantics you describe. They distinguish between
> null/empty/non-empty and none compare as equal to the others. In fact even
> trying to compare a null array throws an exception much like trying to call
> opEquals on a null object reference throws an exception. It's a very
> reasonable thing to do.

Ok.

> The main trouble with Java array semantics is that
> APIs wind up choosing between null and empty fairly randomly and so many
> Java array bugs are introduced by guessing some function returns "empty"
> when it in fact returns null.

I can see how if the situation does not call for a distinction between "exists but is empty" and "does not exist" then the programmer may choose either "" or null to indicate no value. The choice will likely be based on thier personal preference and/or "fear of null" (a phenomenon I have encountered before)

I don't see this possibility as being a good reason to limit flexibility in this way.

> It's easier to focus instead on only
> distinguishing empty/non-empty, which is what D does.

You mean, limit flexibility for the sake of simplicity. I don't like it.

> One can think up APIs where having a third, null, choice would be useful but almost all the time the practical uses of an array are covered by empty/non-empty.

I think it depends on style and the sort of code you write as to whether the situations where a null choice is "required"* are common or not. Personally I come across them often. I also believe that some people just don't see the need for a distinction, i.e. the current readLine implementation.

*(required is perhaps the wrong word, you can probably work around most situation, but the workaround generally is just that, and sub-optimal)

>>> The foreach will stop automatically at eof. It's like a foreach stopping
>>> at the end of an array when it has no more elements. It doesn't run once
>>> more with null - it just stops.
>>
>> Which foreach? My one? Assume now that I remove the eof() check. What
>> happens now?
>
> It would iterate forever

Not if readLine were implemented the way I assumed it would have been.

> just like any loop that doesn't have an ending
> condition.

Bollocks. :)
The ending condition is readLine() returning null (indicating no more lines "exist").

Regan
1 2 3
Next ›   Last »