Mike Kerner wrote:
Jacque and Richard...
So you're basically thinking we should change words, not the behavior? Why
not just change the documentation, then? In the meantime, if the behavior
is to be left alone, there are a variety of functions (especially the
database functions) that have to be fixed to make them work this way.
My own goal here, regardless of its merit or lack thereof, is simply to
maintain compatibility with 25 years of code which was written to expect
delimiters to act as terminators.
As such, I wouldn't advocate deprecating the existing tokens, simply
adding new ones that are clearer, and encouraging folks to use the news
ones going forward.
That should maintain the functionality of the db libs (and anything else
ever written) even after the addition of the synonyms.
Also remember that text editors don't behave this way, either. Empty
<CR>'s at the end of a line still trigger a page break. That seems far
more correct than having to figure out of a delimiter/terminator should be
significant or not.
LiveCode fields follow the same UI convention, but while the cursor is
moved to a lower position when you hit the Return key, there still isn't
any actual data there until you type something; the cursor's position
allows you to add data, but is not data itself.
I suppose we could consider this a philosophical matter, and as such
it's likely that there will always be some disagreement about what's "best".
But as an old friend likes to say, "Best is the enemy of results."
One thing we can all agree on is the recognition that delimiters have
been used as terminators in xTalks for decades, and all code written to
date expects this if it deals with delimiters at all.
The proposed stack property seems a good way to avoid bifurcating the
community code base, and I certainly wouldn't argue if someone takes the
time to do it. Mark Wieder seems well motivated; I'd say go for it,
then everyone gets what they want so long as the default remains as it
is now.
And there's the rub: generations of newcomers would still have a
segment of their population that isn't clear on the notion that
delimiters are terminators.
So completely independent of anything Mark might do to support those who
don't like the current implementation, I still feel that more
descriptive synonyms would be helpful.
Adding a list datatype (and true pointers) would both be great, but one of
the things that has always made xTalk so awesome and amazing is way that
datatypes are generally context-sensitive and implicit nearly everywhere.
It's much less of a world where I have to tell the interpreter/compiler
what I mean, or put .toString() everywhere, and more of it having to do
just that little bit of work for me - in other words, it has to be just a
bit smarter than the table I'm typing at right now. If, by creating more
defined/restrictive datatypes I'm going more the direction of a traditional
language, then LC loses something that, I believe, makes it extra special
when deciding between it and something like Xojo.
I see true lists like arrays, in the sense that you have to go out of
your way to load them and use them, but the benefits of doing so are
compelling enough to be worth the effort.
Like arrays, there are some data representations which just don't lend
themselves well to delimited strings.
So yes, we should continue to make strings more usable, by whatever
means. But I think there's merit in sometimes also considering entirely
new ways to solve problems.
Which leads us to structs....but that's a story for another thread. :)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
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
