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

Richard Gaskin ambassador at fourthworld.com
Sun Aug 11 23:24:09 EDT 2013


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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list