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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
