Handling of final delimter (was Re: "this me"?)

[Richard Gaskin]

Paul D. DeRocco wrote:

>> From: Ben Rubinstein
...
>> are there any examples of LC behaviour which are inconsistent with it?
>
> YES. A listbox that has a return at the end of its contents allows the user
> to select a blank item following the last visible item. When building up the
> contents of the listbox a line at a time, you have to append the line of
> text if it is empty, or append a return and the line of text if it is not.
> Or, you have to append a line of text and a return each time, then remember
> to go back and remove the trailing return if anything was added.

Respectfully, that's a UI control flexibility, not a data processing 
convention.

True, as with other property settings it requires us to be mindful of 
what we set the text to, but there may be times when it can be useful to 
allow the user to select a blank line.

> I'm not saying that behavior is necessarily wrong, it's just that there is
> some precedent for a return at the end implying an empty line. One third way
> to interpret a list would be to say that any trailing stuff that isn't
> followed by a delimiter would be ignored entirely. This would be
> counterintuitive when the delimiter is a printable character (e.g.,
> "a,b,c,d" would ignore the "d"), but has some precedent when the delimiter
> is a return (some parsers ignore an unterminated last line in a text file).

We all have our pet peeves with any language, whether it's JavaScript or 
LiveCode or even English (the absence of a gender-independent 
third-person pronoun comes to mind).

My favorite annoyance with xTalks is the decision by the HyperTalk team 
to allow some functions to be called as though they're properties - but 
not all.  You can say "get the abs of -10" or "abs(-10)", and you can 
say "get offset("l", "hello") but not "get the offset of "l" in "hello".

Stranger still, the "abs" function turns out to be an especially good 
example:  it's an abbreviation for which the long form ("absolute") is 
not permitted. I kid you not.

And with LiveCode specifically, don't get me started about 
"destroyStack". :)

Some of these may be changed over time, but others are too pervasive, 
and the benefits of change less clear.

No programming language is without its gotchas.  In cases where the 
benefit of change is at best debatable, we just have to chalk it up on 
the list of things we have to learn and move on.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys