item delimiter defaults

[Mike Kerner]

You might also be able to make it a default for a particular stack, which
would then go away for substacks, libraries, etc.


On Thu, Nov 21, 2013 at 2:31 PM, Alex Tweedly <alex at tweedly.net> wrote:

>
> 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.
>>
>>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."