item delimiter defaults

[Alex Tweedly]

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.

Thus,
     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


-- Alex.

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
>> overhead.
>
> 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 
> this:
>
>   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.
>