Inconsistent Behavior of Lists

[Alex Tweedly]

At 09:50 16/09/2004 -0400, Frank D. Engel, Jr. wrote:

>Hmm... that explains the strange behavior of lines too.
>
>If I set up a field as a list box with records from a database:
>......
>Which works as I wish it to.  So the list box field looks at that empty 
>line as being a valid, usable line, but the other commands do not?

Not sure just how the list box looked at it, but your description sounds 
convincing.

>Is there a reason why this is also considered consistent?

Yes, kind of.

Forget, for the moment, that you're trying to parse some text - in fact, 
forget about Rev for a moment. If you took any normal text file on most 
computers, the last character would be a <cr> (or equivalent). If you asked 
99.99% of users "what's the last line in this file?" they'd tell you it was 
the sequence of characters up to and including that <cr> (though most of 
them wouldn't really consider the fact that there was a <cr> there, many 
wouldn't even be aware there was).

None of them would tell you the last line was a blank line !

So for normal text processing of normal text files, Rev gives you the 
behaviour expected by most everyone.

But if you look at it from a programmer's viewpoint, then you do indeed run 
into the fact that it is (in some sense) inconsistent.

This difference in viewpoints means that there's no "100% correct" answer 
for everyone - and I think Rev (presumably following all the other xTalks) 
has made a reasonable choice. But it does take some care to avoid "fragile" 
coding.

I've seen a number of example scripts that did something like
  put empty into myVar
  repeat for (some circumstances)
      if (some condition) then put (someVar) & comma after myVar
  end repeat
  delete the last char of myVar -- remove extra trailing comma

which is OK  *only* if you know the last item was not empty (i.e. usually, 
only if empty items are not valid in context).

-- Alex.
-- Alex.