On 2015-10-29 18:11, Ben Rubinstein wrote:
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.
That's the problem if you use functional forms. In an English-like
setting though that concern goes:
<chunk>Offset() => the <chunk> offset of x [ after y ] in z
It is the camel-casing which causes keyword explosion (synonyms aren't
really a problem when you don't have to camel-case things).
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.
Indeed - this is true. We've experimented with English-like syntax for
this in LCB:
the [ first | last ] index of x [ ( before | after ) y ] in z
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 think that might work for the offset() functions - I shall ponder...
The resulting value would probably have to be negative as well - since
offset() and friends return the delta between the starting index and the
found index (which I'm not sure is actually as useful as absolute
offsets).
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
