Ben Rubinstein wrote:
On 29/10/2015 15:47, Richard Gaskin wrote:
Like "lineOffset", "lineAtOffset" would take the same arguments and
operate similarly, but rather than returning the number of the matching
line it would return the text of that line.
...
Of course this could be useful occasionally - but I'm not sure the value
outweighs the cost - not so much the cost of implementation, as the cost of
adding more words to the language.
In code, it saves a single line.
In efficiency, I grant there's a cost; but it seems to me that if the cost was
high (i.e. you're searching in a really long piece of text, and you're doing
it a very large number of times) then you could choose to mitigate that cost
in various ways (e.g. doing split to get an array indexed by line number, or
(depending on your situation) doing "offset" instead of line offset, and then
taking a chunk starting sufficiently before the found character position and
doing "lineoffset" on that...
True, we have alternatives. I guess it boils down to how important we
feel chunk expressions are as a defining part of the language.
Array splits are convenient and an excellent choice if you anticipate
needing to extract values often. But for a one-time lookup, the
overhead of split can outweigh the cost of lineoffset + getting the line
text.
I've been using character offsets for some cases as you describe, and
since offset deals with fixed-size characters it's faster than any other
chunk expression that needs to parse by delimiters. But at that point
the logic of my code starts to resemble how I'd do things in JavaScript
or other common languages, fine for me but not the celebration of chunk
expressions I find resonates with newcomers when I'm teaching the language.
But mainly, I'm agin this proposal because, if there were to be changes to the
offset suite of functions, I'd much rather that effort was spent on making
them work backwards. It's fast and simple to do offset, lineoffset, etc to
find the first occurrence of a fragment, or to walk 'forward' through the
occurrences of a fragment; but it's neither fast nor simple to get the last
occurrence, or to walk backwards through the occurences.
There's an inconsistency here - LC makes it as easy to ask for the last item,
or the third line from the end, as it does the first item, or the third line.
But the *offset functions only work in one direction.
Also note that implementing the backwards offsets needn't (I think) require
adding any new keywords, because we can use the skip parameter with a negative
number.
I don't see the two as mutually exclusive. Isn't there a request for
backwards offset in the RQCC?
Sorry to hijack your thread!
Not at all. My tastes and preferences are only my own, so it's helpful
to get feedback from others.
--
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
