item delimiter defaults
alex at tweedly.net
Thu Nov 21 20:31:51 CET 2013
I suspect that a global property (even with conservative defaults) would
be a source of great problems to library / custom control authors.
How about a different approach - add an optional phrase to the 'item'
keyword, such as "by character", e.g.
put item 1 by COMMA of tColor into tRed
put item 3 by TAB of myVar into tCell3
Come to think of it, while I'm asking for some features to do with
items, I would really like
put the items of myVar into t1, t2, t3
which would split out the items into multiple variables - with the last
named var getting all remaining items.
put "a,b,c,d,e" into tAll
put the items of tAll into t1, t2, t3
would result in
t1 == a
t2 == b
t3 == c,d,e
And of course you could also do
put the items by COMMA of Color into tRed, tGreen, tBlue
On 21/11/2013 18:45, J. Landman Gay wrote:
> On 11/21/13 12:19 PM, Bill Vlahos wrote:
>> The only problem I see in making this change now is that it will
>> break some apps. If I give or get a stack from someone who defaults
>> to a different delimiter things will break in funny ways.
>> Perhaps there can be a statement in some standard place such as
>> preOpenStack like “set the itemDelimiter to XXX” or a stack Custom
>> Property. LiveCode IDEs after a certain date will read and set it and
>> if it isn’t there the current behavior of comma will be used as the
>> default. This would provide backwards compatibility without much
> I use commas all the time, and so does the engine. The default
> delimiter for all native properties is comma (colors, rects, etc.) and
> changing it universally would break almost all legacy stacks.
> However, that said, I think the original request was for the developer
> to be able to specifically set a global delimiter, which would be the
> correct way to implement this. The default global delimiter would be a
> comma, as it is now. But there would be a command to change that,
> which authors could use if they wanted it.
> set the globalDelimiter to tab
> That could be executed anywhere in any script and would change the
> global propery until it was changed again. Legacy stacks would remain
> unaffected because the engine default would be comma as it is now.
> I do think it will cause the same issues that we had in HyperCard,
> where setting the itemDelimiter was global instead of
> handler-specific. I welcomed the revised use of item delimiters back
> in MetaCard because I no longer had to bracket every change with
> saving the old one, using the new one, and then restoring the old one.
> Keeping the delimiter handler-specific was a godsend that made
> scripting much easier.
> Providing a way to implement this older HC behavior could cause the
> same issues. Every time you want to extract the components of a
> rectangle, a color, or any other native property, you will have to do
> put the itemDelimiter into tOldDel
> set the itemDelimiter to comma
> put item 1 of tColor into tRed
> set the itemDelimiter to tOldDel
> That's what we had to do in HC and I guarantee it's a pain in the patoot.
More information about the use-livecode